Text Blame History Raw

Board minutes 2016-06-15


  • Jim Perrin
  • KB Singh (Chair)
  • Fabian Arrotin
  • Johnny Hughes
  • Karsten Wade (Secretary, meeting #2)
  • Michael McLean
  • Ralph Angenendt
  • Carl Trieloff


  • Richard Megginson (OpsTools SIG)
  • Matthias Runge (OpsTools SIG)

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

## 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

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