16:03:30 <roidelapluie> #startmeeting CentOS Config Management SIG
16:03:30 <centbot> Meeting started Wed Mar 23 16:03:30 2016 UTC.  The chair is roidelapluie. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:30 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:03:34 <roidelapluie> #topic Agenda
16:03:37 <roidelapluie> #info Topic: Welcome and Thanks / Presentation of the SIG for the folks in #centos-devel
16:03:40 <roidelapluie> #info Topic: Election of the SIG Chair AND Co-Chair / decisions about SIG governance
16:03:43 <roidelapluie> #info Topic: Validation of the content of the SIG presentation in the Wiki
16:03:45 <roidelapluie> #info Topic: Decisions about Koji tags (per projects) / Introduction to CBS (with bstinson)
16:03:48 <roidelapluie> #info Topic: Future plans for CI
16:03:49 <roidelapluie> #info Topic: How to deal with security (interactions with upstream mailing lists/Centos security team etc)
16:03:52 <roidelapluie> #info Topic: Schedule of the Next Meetings
16:03:52 <roidelapluie> #info Topic: Next steps
16:03:54 <roidelapluie> #info Topic: Misc
16:03:56 <roidelapluie> #chair kbsingh Arrfab
16:03:56 <centbot> Current chairs: Arrfab kbsingh roidelapluie
16:03:59 <roidelapluie> #topic Welcome and Thanks / Presentation of the SIG for the folks in #centos-devel
16:04:02 <roidelapluie> #link https://wiki.centos.org/SpecialInterestGroup/ConfigManagementSIG is the wiki page for the SIG
16:04:09 <roidelapluie> Hello everyone
16:04:13 <sc`> ohai o/
16:04:28 <roidelapluie> This is the first cfgmgmt sig meeting
16:04:54 <roidelapluie> I would like to thank everyone to be there and to have permitted to this SIg to start
16:05:02 <alphacc> o/
16:05:10 * fcami waves
16:05:15 <kbsingh> hello
16:05:27 <roidelapluie> the goal of this meeting is to be able to start the actual work as soon as possible
16:06:11 <roidelapluie> The SIG is about providing CentOS users access to lifecycle management tools
16:06:43 <roidelapluie> Puppet, Chef, Rudder, Salt and Ansible are part of the initial list
16:07:41 <roidelapluie> There are 2 people whe have declined the invitation so I expect a few people to be there
16:08:02 <roidelapluie> I will introduce myself firsc
16:08:06 <roidelapluie> first*
16:08:28 <roidelapluie> I bootstrapped the SIG, my main interest is Puppet
16:08:40 <roidelapluie> I am a sysadmin using CentOS everyday
16:09:01 <roidelapluie> If anyone wants to introduce himself, please do
16:09:49 <fcami> <= infrastructure/platform consultant @ Red Hat, Ceph maintainer for the CentOS Storage SIG, interested in Ansible on behalf of the Storage SIG as it will be used in Ceph Jewel
16:09:58 <jooooooon> hi, I'm late and I'm jooooooon, I work on Rudder (http://www.rudder-project.org) a config mgmt tool with a web GUI and compliance info (also do some CFEngine, so can help out there)
16:10:34 <dmurphy18> Hi David (dmurphy18), work at Salt on packaging
16:11:05 <kenny1> I'm Kenny and I work with LCFG (http://www.lcfg.org).
16:11:41 <roidelapluie> Welcome everyone
16:11:57 <kbsingh> I'm KB, recovering CentOS contributor / developer / lead
16:12:17 <kbsingh> mostly here to see how we can facilitate you guys, and also covering for Fabian who's unable to be here for the meeting
16:12:33 <sc`> <- Sr. Infrastructure Systems Engineer @ Workday (IOW, bare metal engineering), incoming PTL for the Chef OpenStack project for the Newton cycle. my focus is on Chef, as it is the tool I use the most
16:12:37 <roidelapluie> I hope we will have the chance to get bstinson later in the meeting
16:12:58 <roidelapluie> #topic Election of the SIG Chair AND Co-Chair / decisions about SIG governance
16:13:18 <roidelapluie> Let's start by the governance
16:13:30 <bstinson> roidelapluie: hey, i'm here
16:13:41 <roidelapluie> welcome bstinson :)
16:14:03 <roidelapluie> I have written some rules to cover the way the SIG should work
16:14:19 <roidelapluie> #link https://wiki.centos.org/SpecialInterestGroup/ConfigManagementSIG/Governance
16:14:44 <roidelapluie> Here is the goal:
16:15:15 <roidelapluie> 1. Ensure that the SIG is not managed by one person only
16:15:39 <roidelapluie> so if the Chair is off someone takes its tasks
16:16:21 <roidelapluie> 2. Ensure that anyone can become chair  -- and that the chair changes (or can change) every year
16:17:07 <roidelapluie> The other part of the rules is basic: we do belong to the centos project and the CentOS board can change the rules
16:18:09 <roidelapluie> The main task of the chair is to propare the meetings
16:18:54 <roidelapluie> I will be a candidate as Chair for the first year
16:19:39 <roidelapluie> I propose we validate the rules today, make a call of the list and vote for the chair/co-chair in the next meeting. What do you think?
16:19:53 <roidelapluie> make a call on the list*
16:20:14 <jooooooon> sounds good to me
16:20:28 <kenny1> Yes.
16:20:31 <sc`> sounds like a reasonable start
16:20:42 <alphacc> roidelapluie: sounds good, we never had a formal process for election so far but +1 for me
16:20:52 <kbsingh> one model that works well for other sig's - and we were talking about this in the PaaS Sig just before now - is to just dilute the responsibilities of the chair
16:21:08 <kbsingh> so have a named set of people who are a 'commitee' and just have them all be able to take on chair responsibilities
16:21:23 <kbsingh> everyone else is a member, and the committee can pull from members as needed ( or not )
16:22:00 <roidelapluie> kbsingh: the advantage of a chair is that he/she is in charge of taking initiatives
16:22:10 <kbsingh> one thing that the chair is really needed for - is to have 1 person who can ack/nack new members
16:22:17 <kbsingh> but you can have a group of people able to do this
16:22:48 <sc`> i think with a multi-focus group like this, it's reasonable to approach it like that
16:23:22 <roidelapluie> okay, so let me resume the proposal
16:23:54 <roidelapluie> Instead of a Chair/Co-Chair, make a comitee
16:24:15 <roidelapluie> Everyone has the same responsibilities
16:24:21 <roidelapluie> in the comitee
16:24:44 <roidelapluie> I do agree with that.
16:24:55 <sc`> +1
16:25:52 <roidelapluie> Members of the comitee would also engage themselve for 12 months, and should be elected as well
16:26:05 <roidelapluie> That way inactive people do not stick at that position
16:26:56 <roidelapluie> Do we agree on that?
16:27:51 <kbsingh> sure
16:27:55 <kenny1> I agree.
16:27:59 <sc`> i'm good with it
16:28:18 <roidelapluie> #action roidelapluie to rewrite the governance rules to include the comitee
16:28:25 <jooooooon> I guess. The sooner we get to work, the happier I am, I'm not too worried about the 5-10 of us being able to collaborate :)
16:28:58 <roidelapluie> #action roidelapluie to send a mail to centos-devel to call for comitee members
16:29:12 <roidelapluie> #agreed the SIG will be managed by a comitee
16:29:18 <roidelapluie> #info Topic: Validation of the content of the SIG presentation in the Wiki
16:29:24 <roidelapluie> #topic Validation of the content of the SIG presentation in the Wiki
16:29:43 <roidelapluie> So there some content of the wiki
16:29:58 <roidelapluie> if anyone has some comments about that.. please tell
16:30:07 <roidelapluie> otherwise we can go to the next point
16:30:22 <bstinson> i have a short thing that feeds into the koji tag discussion
16:30:47 <roidelapluie> ok let's move
16:30:49 <roidelapluie> #topic Decisions about Koji tags (per projects) / Introduction to CBS (with bstinson)
16:30:50 <bstinson> on the wiki the group name in ACO is listed as sig-cfgmgmt, but the group is actually sig-configmanagement
16:31:05 <roidelapluie> bstinson: I will fix the wiki
16:31:46 <roidelapluie> bstinson: can you give a short intro about CBS
16:31:48 <bstinson> cool, if we're ok with using configmanagement as the 'shortname' of the SIG that would be helpful
16:32:21 <roidelapluie> bstinson: and some  links to the relevant documentation
16:32:51 <bstinson> sure, http://cbs.centos.org/ is where you'll see a bunch of SIG activity, and is where your builds will happen
16:33:16 <bstinson> #link https://wiki.centos.org/HowTos/CommunityBuildSystem
16:33:41 <bstinson> the quickstart there will get you through most of the details but we can talk about higher-level stuff here
16:34:02 <roidelapluie> bstinson: CBS is not used for CentOS linux?
16:34:23 <bstinson> nope, separate buildsystems
16:34:28 <roidelapluie> ok
16:35:00 <bstinson> what you do get is a set of tags that inherit CentOS Linux to start, and you can build your projects (and their dependencies) on top of that
16:35:15 <jooooooon> I'm sorry but I have to split - an impromptu visit to the office I can't avoid. Really sorry, guys.
16:35:50 <bstinson> you can request new tags any time by filing a bug in bugs.centos.org under the Buildsys project
16:36:20 <bstinson> let's take puppet for an example
16:36:38 <bstinson> you'll get the following tag structure:
16:37:28 <bstinson> configmanagement7-puppet-38-candidate
16:37:37 <bstinson> configmanagement7-puppet-38-testing
16:37:41 <bstinson> configmanagement7-puppet-38-release
16:38:21 <roidelapluie> #info New tags are needed to build into CBS
16:38:45 <roidelapluie> #info Each projects needs to have its own tags. e.g. configmanagement7-puppet-38-candidate configmanagement7-puppet-38-testing configmanagement7-puppet-38-release
16:38:45 <kbsingh> is there a common target for all of the sig as well ?
16:39:01 <bstinson> yes
16:39:41 <bstinson> to give you an idea of where that structure comes from:
16:39:55 <bstinson> #link https://wiki.centos.org/SIGGuide/Content/GitBranchesandKojiTags
16:40:14 <roidelapluie> I do think that for Puppet we will need multiple tags: puppet44, puppetserver23, hiera3
16:40:24 <roidelapluie> bstinson: we also depend on EPEL packages
16:40:46 <roidelapluie> should we build them in 'scl-like' packages?
16:40:46 <bstinson> will those be shipping together?
16:41:12 <roidelapluie> bstinson: some of them are only for build-time, other will be shipped
16:41:32 <roidelapluie> e.g cmake3 is for build time
16:41:33 <bstinson> the way to depend on EPEL packages is to grab the SRPMs and build them somwhere in your tag structure (other SIGs are putting as much as they can in common)
16:42:07 <roidelapluie> bstinson: in that case it does not allow people to have the EPEL package
16:42:41 <roidelapluie> if EPEL changes the version of the package, people will need to chose
16:43:03 <bstinson> you'll need to ship with repoclosure, and you can't assume that they have EPEL installed
16:43:34 <roidelapluie> bstinson: what I mean is: is there something wrong by making a SCL for those packages?
16:43:36 <fcami> roidelapluie: EPEL as per policy will probably not change package versions unless 100% compatible
16:43:44 <roidelapluie> ok
16:44:03 <fcami> with that said, other SIGs tend not to depend on EPEL so far
16:44:04 <bstinson> roidelapluie: not at all, that's certainly one way to ship
16:44:18 <roidelapluie> #info fcami:  EPEL as per policy will probably not change package versions unless 100% compatible
16:44:40 <roidelapluie> ok
16:45:12 <bstinson> the point being, if you ship vanilla RPMs you need to carry around the dependencies as well
16:45:37 <roidelapluie> #action SIG members to send tag requests to bugs.centos.org
16:45:43 <fcami> roidelapluie: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Some_examples_of_what_package_updates_that_are_fine_or_not for more info
16:45:53 <roidelapluie> #link https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Some_examples_of_what_package_updates_that_are_fine_or_not
16:45:57 <roidelapluie> thanks fcami
16:46:29 <roidelapluie> I remember RHEL shipping a package from EPEL in another version
16:46:44 <roidelapluie> A nginx dependency
16:46:54 <roidelapluie> I would rather give a try a the scl
16:47:25 <roidelapluie> kbsingh: is that okay to use /opt/centos-configmanagement for the SCL?
16:47:52 <bstinson> iirc vendor directories under /opt need to be registered
16:48:10 <fcami> with lanana
16:48:15 <roidelapluie> bstinson: yes, we can register if needed
16:48:24 <roidelapluie> /opt/centos is registered
16:48:47 <roidelapluie> but then we would conflict with other SIG in the future
16:49:34 <roidelapluie> Do we agree about /opt/centos-configmanagement if a SCl is needed?
16:49:54 <kenny1> Does centos hold a registry of names under /opt/centos?
16:50:23 <roidelapluie> AFAIK FHS does not permit sbudirectories
16:50:42 <roidelapluie> /opt/centos/configmanagement is not an option
16:50:44 <bstinson> i think this needs wider discussion, especially with the rest of the Core SIG members
16:50:51 <roidelapluie> ok
16:50:53 <bstinson> is this on the mailing list?
16:50:56 <roidelapluie> no
16:51:01 * bstinson is a bit behind on emails :)
16:51:13 <roidelapluie> #action roidelapluie to contact the list about SCL prefixes
16:51:20 <roidelapluie> #topic Future plans for CI
16:51:26 <roidelapluie> Let's move
16:51:30 <sc`> chef already installs self-contained in the traditional installation method. i don't think it'd be a problem to relocate from /opt/chef
16:51:43 <sc`> sorry, attention split
16:51:46 <roidelapluie> :)
16:51:49 <sc`> 3 meetings at once :)
16:52:22 <fcami> roidelapluie: before we dig into CI, do you guys have a dist-git system setup yet?
16:52:34 <roidelapluie> fcami: no
16:52:58 <fcami> roidelapluie: FYI the Storage SIG uses https://github.com/orgs/CentOS-Storage-SIG/teams = a github org for the SIG and teams for the projects. Works for us.
16:53:33 <roidelapluie> we would like to have as much automation as possible, so here is what I would like to have
16:54:03 <roidelapluie> 1. integration between koji and github (maybe with jonkins in the middle)
16:54:14 <roidelapluie> Pull Requests make scratch builds
16:54:28 <roidelapluie> Commits on branches make testing builds
16:55:02 <roidelapluie> 2. After each successful scratch/release builds, CI tests are run
16:55:10 <sc`> could use gerrit for that
16:55:21 <roidelapluie> and test results are sent back to github
16:55:36 <roidelapluie> sc`: CentOS does not have gerrit
16:56:16 <roidelapluie> and using gerrithub is adding another SPOF and it still requires a gathub account
16:56:35 <roidelapluie> as said in the wiki: However, as there is no code review tool integrated with git.c.o, we use github and github pull requests. We do not use gerrithub because it would be an extra layer that we do not manage and it would still require a presence on github. Still we would support any effort of the CentOS project to have an internal code review tool.
16:56:40 <sc`> fair point
16:57:31 * sc` nudges kbsingh
16:57:33 <bstinson> i think it's a great idea to be thinking about automation, i would say it's probably a good idea to run a couple of releases through the process manually to work out the edges
16:58:26 <roidelapluie> bstinson: automation is not for tomorrow anyway
16:58:36 <roidelapluie> this isthe ideal I would see
16:58:45 * kbsingh reads up
16:59:00 <kbsingh> roidelapluie: for the SCL's i think its between you guys and the scl definitions.
16:59:21 <roidelapluie> Public members of the SIG would have all their PR tested/scratch built
16:59:22 <kbsingh> roidelapluie: in this case, that would be to use /opt/centos/<component> I believe ( but i might be wrong, its worth looking back at the spec )
16:59:59 <roidelapluie> and external contributors would need to wait for a public member approval
17:00:02 * fcami has to run, cya folks
17:00:08 <roidelapluie> like the foreman pnoject does
17:00:15 <roidelapluie> like the foreman project does
17:00:15 <sc`> cheers fcami
17:00:18 <roidelapluie> cheers
17:00:30 <roidelapluie> I propose to write that down
17:00:35 <roidelapluie> in the wiki
17:00:36 <kbsingh> so on the integration point- you cant push to cbs. from github without there being someone who takes ownership of the bits
17:00:47 <kbsingh> so by definition, we wont permit automation between github and the build services
17:01:15 <kbsingh> this is a key requirement, that allows us to work without CLA's and paperwork needed for signups and fluff like that
17:01:45 <roidelapluie> I do not understand the CLA stuff
17:01:50 <kbsingh> in effect, everyone contributing would need to have an account on a.c.o - and would need a +1 from the SIG ( chair / commitee ) in order to push content
17:02:22 <roidelapluie> yeah that is the part that I would like to automate
17:02:26 <kbsingh> i.e once bootstrapped, you guys will need to know and do due delligence before adding more people - since you take personal responsiblity for the content that person will push
17:02:54 <roidelapluie> that is the same with github pull requests
17:03:18 <roidelapluie> 1. membir of the SIG needs to pre-validate contributions from outside -- with a comment lik
17:03:24 <roidelapluie> like [test]
17:04:05 <roidelapluie> 2. members of the SIG would get the feedback from CI and commets from peers in the PR
17:04:43 <roidelapluie> kbsingh: I will write that down for further discussions with the core sig
17:05:03 <roidelapluie> I propose we move further
17:05:07 <kbsingh> roidelapluie: well, its the lawyers that need to agree. But yes, write it down and send it and i will try and either fit it into what we have agreed already or try and take it there
17:05:25 <roidelapluie> #topic How to deal with security (interactions with upstream mailing lists/Centos security team etc)
17:05:28 <kbsingh> once we have git.centos.org setup for direct commits, this becomes easier, since cbs.c.o can then integrate with git.c.o
17:05:35 <roidelapluie> ok
17:05:52 <roidelapluie> kbsingh: I just have some small guestions
17:06:17 <roidelapluie> questions*
17:06:29 <roidelapluie> kbsingh: do we have access to centos-announce?
17:06:44 <roidelapluie> e.g. in case of security updates
17:07:07 <kbsingh> no
17:07:20 <kbsingh> ( there is a process under dev at the moment that will fix that though )
17:07:29 <roidelapluie> and do we need to join (as a sig) a security group inside centos?
17:07:33 <kbsingh> nope
17:07:51 <kbsingh> there is a security@centos.org expander that will triage and then report to the SIG commitee for escalation if needed
17:07:53 <roidelapluie> e.g if there is a security update, we can not test our packages against the release?
17:08:14 <kbsingh> there are no embargo builds in cbs.c.o if thats the question...
17:08:21 <roidelapluie> ok
17:08:45 <kbsingh> what did you mean by 'security group' ?
17:09:10 <kbsingh> security@centos.org is an inbound channel for people wanting to report issues... very few people do, since they would engage with upstreams directly instead
17:09:31 <roidelapluie> I was thinking that there are security meetings inside the core sig
17:09:32 <roidelapluie> ok
17:09:35 <kbsingh> eg: if someone reported an issue around puppet, we would contact the puppet security team
17:09:46 <kbsingh> if they say speak to roidelapluie, then we'd loop you into the convo as well
17:09:56 <roidelapluie> ok
17:10:14 <kbsingh> unless you can demonstrate you are a part of the puppet security team ( which makes our lives easier )
17:10:25 <kbsingh> eg in the case of gwd and xen
17:10:33 <roidelapluie> ok
17:10:38 <vincent_vdk> just here
17:10:46 <roidelapluie> hello vincent_vdk
17:10:50 <vincent_vdk> hi
17:11:00 <vincent_vdk> got a busy day today ..
17:11:24 <roidelapluie> vincent_vdk: we are almost done
17:11:27 <roidelapluie> #topic Schedule of the Next Meetings
17:11:44 <roidelapluie> The next meeting will happen on the 13th April
17:12:04 <roidelapluie> I did not read the calendar correctly for this meeting
17:12:25 <vincent_vdk> ok
17:12:28 <kbsingh> do you have a wish list in terms of what you'd like to cover between now and then ?
17:12:32 <roidelapluie> but we will get bach to the correct week for the next meeting - so in 3 weeks
17:12:46 <roidelapluie> kbsingh: what do you mean?
17:12:55 <kbsingh> ie. get cbs tags in, get every component to validate their access is setup, do one round of rpm builds, maybe close the /opt/ conversation ?
17:13:34 <roidelapluie> kbsingh: yes
17:13:45 <kbsingh> cool :)
17:13:46 <roidelapluie> semo of them are action points already
17:13:49 <roidelapluie> some
17:14:18 <vincent_vdk> did you guys discuss possible 'clashes' with epel?
17:14:25 <roidelapluie> vincent_vdk: yes
17:14:33 <vincent_vdk> afaik Ansible is already there
17:14:33 <kbsingh> excellent, feel free to ping if there is anything i can help with. I might be in and out over the next 10 days or so, but will reply
17:14:51 <vincent_vdk> bu I know people like access to rpm repos for that
17:15:12 <kbsingh> i thought we had someone representing ansible here in the SIG already
17:15:13 <vincent_vdk> ok, I'll go through the history here then
17:15:20 <vincent_vdk> ah
17:15:25 <roidelapluie> vincent_vdk: ze did not talk about that
17:15:36 <roidelapluie> only about dependencies
17:15:44 <roidelapluie> vincent_vdk: wait
17:15:48 <roidelapluie> #topic Misc
17:16:04 <kbsingh> ... you cant dep on epel for content, if you need bits from there, you need to pull them into cbs and build here
17:16:09 <roidelapluie> vincent_vdk: what would you do for ansible?
17:16:27 <roidelapluie> 1. Nothing
17:16:44 <roidelapluie> 2. Build with a epoch higher than EPEL
17:17:01 <roidelapluie> 3. Build in a SCL
17:17:29 <roidelapluie> I would avoid (2) because that is not nice for users
17:17:44 <vincent_vdk> roidelapluie: basically provide up to date packages for Ansible
17:17:55 <roidelapluie> I would avoid (3) because I would like that we provide /usr/bin/ansible
17:18:05 <kbsingh> also note that there are lots of opportunities to enage with other SIGs around content
17:18:15 <kbsingh> eg. the openstack guys in CloudSIG already build puppet
17:18:28 <kbsingh> similarly, i am sure there is traction around ansible as well
17:18:42 <roidelapluie> vincent_vdk: I think that if you install the cfgmgntsig repos you expect that we provide an ansible that conflicts with EPEL
17:19:07 <kbsingh> 4. ship a container for Ansible
17:19:43 <roidelapluie> I also have to run off guys
17:20:19 <roidelapluie> vincent_vdk: if you have concerns about EPEL, can you bring that to the list before the next meeting?
17:21:01 <roidelapluie> #action roidelapluie to propose to everyone to play with CBS before the next meeting
17:21:22 <alphacc> I would also keep an eye on what redhat ships and what can be rebuilt similar to sclo process casue it will be something users may like.
17:21:39 <roidelapluie> #info Next meeting will be in 3 weeks
17:22:33 <roidelapluie> #info thanks to everyone attending the meeting. Please reach centos-devel mailing list for further discussions.
17:22:38 <roidelapluie> #endmeeting