| |
@@ -16,75 +16,82 @@
|
| |
## Agenda & notes
|
| |
|
| |
### Optools SIG
|
| |
- Lack of tools in CentOS (and Fedora) for operators of large infrastructure/installations
|
| |
- Doesn’t fit in e.g. Cloud SIG
|
| |
- Home for these tools + bits and pieces to install/config infrastructure
|
| |
- E.g. if logging, there are good & bad examples of what to log, how to log, etc.
|
| |
- So provide a guide of how-to install each specific tool, what to watch, etc.
|
| |
- E.g. OpenStack installations log way too much, including things that are not errors but look like errors, so need some filtering afterwards.
|
| |
- Useful outside of each specific SIG.
|
| |
- Relationship with Config Mgmt SIG
|
| |
- Would provide manifests/playbooks/recipes/etc. To get tools installed would first look to existing sources in CentOS & SIGs.
|
| |
- Configs ultimately belong to the Config Mgmt SIG.
|
| |
- Working against duplicated efforts in tools stacks
|
| |
- Diff stacks of software reimplement or bring in the same tools
|
| |
- Use case: correlate logs amongst all these things
|
| |
- E.g. openshift on top of openstack, want to be able to correlate the logged error into each part of the stack - storage, underlying OS, orchestration, etc.
|
| |
- Give operators tools to do deep-cause analysis
|
| |
- KB - having ELK, graphon, etc. in the project helps on community side as we have a very operator-heavy base, many potential consumers.
|
| |
- Proposal is on the wiki -- https://wiki.centos.org/SpecialInterestGroup/OpsTools
|
| |
- What about the lack of upstream connection? Are any SIG members from the relevant upstream projects.
|
| |
- Most things are not in our direct control, refer back up to EPEL.
|
| |
- Willing to build bridges into upstreams where there are no existing upstream developers here
|
| |
- Talking with actual upstream developers.
|
| |
- Elastic is changing to an ‘open core’/’commercial open source’ model
|
| |
- Have some contributions in
|
| |
- Paying attention to open source replacements for problematic source models.
|
| |
- Can start with current proposed package set, but can replace components one-at-a-time without disrupting user experience.
|
| |
- Provide modularity so we’re not locked in
|
| |
- “Log collector package” -- don’t need to know what is underneath, but can choose if you prefer.
|
| |
- Vote - Should the OpsTools SIG proposal be accepted and the SIG move forward?
|
| |
- +1 from all present
|
| |
- Tru vote, comments, questions requested
|
| |
+ * Lack of tools in CentOS (and Fedora) for operators of large infrastructure/installations
|
| |
+ * Doesn’t fit in e.g. Cloud SIG
|
| |
+ * Home for these tools + bits and pieces to install/config infrastructure
|
| |
+ * E.g. if logging, there are good & bad examples of what to log, how to log, etc.
|
| |
+ * So provide a guide of how-to install each specific tool, what to watch, etc.
|
| |
+ * E.g. OpenStack installations log way too much, including things that are not errors but look like errors, so need some filtering afterwards.
|
| |
+ * Useful outside of each specific SIG.
|
| |
+ * Relationship with Config Mgmt SIG
|
| |
+ * Would provide manifests/playbooks/recipes/etc. To get tools installed would first look to existing sources in CentOS & SIGs.
|
| |
+ * Configs ultimately belong to the Config Mgmt SIG.
|
| |
+ * Working against duplicated efforts in tools stacks
|
| |
+ * Diff stacks of software reimplement or bring in the same tools
|
| |
+ * Use case: correlate logs amongst all these things
|
| |
+ * E.g. openshift on top of openstack, want to be able to correlate the logged error into each part of the stack - storage, underlying OS, orchestration, etc.
|
| |
+ * Give operators tools to do deep-cause analysis
|
| |
+ * KB - having ELK, graphon, etc. in the project helps on community side as we have a very operator-heavy base, many potential consumers.
|
| |
+ * Proposal is on the wiki -- https://wiki.centos.org/SpecialInterestGroup/OpsTools
|
| |
+ * What about the lack of upstream connection? Are any SIG members from the relevant upstream projects.
|
| |
+ * Most things are not in our direct control, refer back up to EPEL.
|
| |
+ * Willing to build bridges into upstreams where there are no existing upstream developers here
|
| |
+ * Talking with actual upstream developers.
|
| |
+ * Elastic is changing to an ‘open core’/’commercial open source’ model
|
| |
+ * Have some contributions in
|
| |
+ * Paying attention to open source replacements for problematic source models.
|
| |
+ * Can start with current proposed package set, but can replace components one-at-a-time without disrupting user experience.
|
| |
+ * Provide modularity so we’re not locked in
|
| |
+ * “Log collector package” -- don’t need to know what is underneath, but can choose if you prefer.
|
| |
+ * Vote - Should the OpsTools SIG proposal be accepted and the SIG move forward?
|
| |
+ * +1 from all present
|
| |
+ * Tru vote, comments, questions requested
|
| |
+
|
| |
### ## SIGs ready for rise up?
|
| |
- Cloud SIG getting quite close
|
| |
- Work is having a lot of influence on downstream
|
| |
- Sorting out how that’s going to work
|
| |
- Maybe segregate RH parts?
|
| |
- Maturing very quickly
|
| |
- Expect to see them in self-admin mode soon-ish
|
| |
- PaaS SIG very organized
|
| |
- Closed group
|
| |
- Quite RH focused
|
| |
- Not ready yet, maybe next meeting or so?
|
| |
- Virt SIG
|
| |
- Established, self-organized
|
| |
- But … George Dunlap is moving from packaging to developing upstream
|
| |
- He’s actively looking for a takeover
|
| |
- Waiting for leadership shift
|
| |
+
|
| |
+ * Cloud SIG getting quite close
|
| |
+ * Work is having a lot of influence on downstream
|
| |
+ * Sorting out how that’s going to work
|
| |
+ * Maybe segregate RH parts?
|
| |
+ * Maturing very quickly
|
| |
+ * Expect to see them in self-admin mode soon-ish
|
| |
+
|
| |
+ * PaaS SIG very organized
|
| |
+ * Closed group
|
| |
+ * Quite RH focused
|
| |
+ * Not ready yet, maybe next meeting or so?
|
| |
+
|
| |
+ * Virt SIG
|
| |
+ * Established, self-organized
|
| |
+ * But … George Dunlap is moving from packaging to developing upstream
|
| |
+ * He’s actively looking for a takeover
|
| |
+ * Waiting for leadership shift
|
| |
+
|
| |
### Credit Suisse
|
| |
- SE Asia operations invests 5 to 7 mil in corporate social responsibility, including into technology
|
| |
- Hosting contests, giving away laptops, etc.
|
| |
- Want to spend on FLOSS projects
|
| |
- Moving dev environment from Debian to CentOS
|
| |
- Have 150 servers to contribute to FOSS projects
|
| |
- Spread across: Singapore, Hong Kong, Tokyo, Sydney
|
| |
- Need to handle hosting ourselves
|
| |
- Can we get that DC space?
|
| |
- Yes, via RH sponsorship, we can start this
|
| |
- Additional discussions
|
| |
- Host Dojos
|
| |
- Sponsor local community people in those specific countries
|
| |
- Reasonable interest in that piece
|
| |
- Sponsorship level?
|
| |
- Likely they host the details themselves
|
| |
- We may not need to create a ‘level’
|
| |
- Support might be 1 to 4 years through their contracts, depending on how much we have installed
|
| |
- Might be a foot in the door toward further contributions that are equally or more meaningful.
|
| |
- Value
|
| |
- What is the value of these machines v. cost to us to host v. canvassing for more hosting?
|
| |
- 7 July call to thrash out synergy
|
| |
- Figure out hosting costs
|
| |
+ * SE Asia operations invests 5 to 7 mil in corporate social responsibility, including into technology
|
| |
+ * Hosting contests, giving away laptops, etc.
|
| |
+ * Want to spend on FLOSS projects
|
| |
+ * Moving dev environment from Debian to CentOS
|
| |
+ * Have 150 servers to contribute to FOSS projects
|
| |
+ * Spread across: Singapore, Hong Kong, Tokyo, Sydney
|
| |
+ * Need to handle hosting ourselves
|
| |
+ * Can we get that DC space?
|
| |
+ * Yes, via RH sponsorship, we can start this
|
| |
+
|
| |
+ * Additional discussions
|
| |
+ * Host Dojos
|
| |
+ * Sponsor local community people in those specific countries
|
| |
+ * Reasonable interest in that piece
|
| |
+ * Sponsorship level?
|
| |
+ * Likely they host the details themselves
|
| |
+ * We may not need to create a ‘level’
|
| |
+ * Support might be 1 to 4 years through their contracts, depending on how much we have installed
|
| |
+ * Might be a foot in the door toward further contributions that are equally or more meaningful.
|
| |
+ * Value
|
| |
+ * What is the value of these machines v. cost to us to host v. canvassing for more hosting?
|
| |
+ * July call to thrash out synergy
|
| |
+
|
| |
+ * Figure out hosting costs
|
| |
|
| |
|
| |
|
| |