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