# Board minutes 2016-06-15

## Attendees
* Jim Perrin
* KB Singh (Chair)
* Fabian Arrotin
* Johnny Hughes
* Karsten Wade (Secretary, meeting #2)
* Michael McLean
* Ralph Angenendt
* Carl Trieloff
## Guests
* 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