# 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