14:31:32 #startmeeting CentOS SIG 14:31:32 Meeting started Tue Sep 23 14:31:32 2014 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:31:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:31:32 Meeting started Tue Sep 23 14:30:57 2014 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:31:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:31:36 there are a bunch of other things going on as well, tying to close those down 14:32:31 OK, let's get started 14:32:37 so - I didn't receive any other agenda items 14:32:51 first things I had on the agenda were 14:33:00 * request for a git repository on git.centos.org 14:33:13 * access to JSON files & build system that's been used so far for builds. 14:33:21 any other items this week? 14:33:34 jzb: can you share #chair? 14:33:43 No! Mine! 14:33:47 Yes, hang on 14:34:08 #chair quaid kbsingh jbrooks walters 14:34:08 Current chairs: jbrooks jzb kbsingh quaid walters 14:34:08 Current chairs: jbrooks jzb kbsingh quaid walters 14:34:15 * build locations and sources 14:34:16 quaid: sorry 'bout that. too early. 14:34:19 #topic Agenda 14:34:30 #info request for a git repository on git.centos.org 14:34:39 #info access to JSON files & build system that's been used so far for builds. 14:34:41 * bexelbie is here 14:34:47 #chair bexelbie 14:34:47 Current chairs: bexelbie jbrooks jzb kbsingh quaid walters 14:34:47 Current chairs: bexelbie jbrooks jzb kbsingh quaid walters 14:34:48 #info build locations and sources 14:35:09 a pony and some cotton candy... 14:35:14 * jzb worth a shot. 14:35:34 is Ian here ? 14:35:43 no.. 14:35:52 I just realized 5 min ago we didn't invite him, just asked him on IRC 14:36:02 so, what do we want to put in that git repo on git.centos.org 14:36:08 where's the git repo? 14:36:13 #topic git repo 14:36:43 kbsingh, the json files, anything else required to compose the tree 14:37:36 jbrooks: would we keep packages there that aren't in official CentOS? 14:37:42 or those sources elsewhere? 14:37:58 I don't know -- how are other sigs doing it? 14:37:59 so, something like bld-cloud-instance... 14:38:07 who's listed as the SIG chair ? 14:38:23 http://wiki.centos.org/SpecialInterestGroup 14:38:24 well 14:38:30 step-1, get the SIG proposal online 14:38:46 http://lists.centos.org/pipermail/centos-devel/2014-June/011225.html 14:38:47 http://wiki.centos.org/SpecialInterestGroup/Atomic 14:38:52 kbsingh: it's been online 14:39:23 I thought it was approved, too? Maybe not yet 14:39:25 it needs to be on the SIG's page, in an appropriate section 14:39:44 kbsingh: just out of curiosity, who does that? 14:39:52 does which? 14:39:56 kbsingh: b/c it was "approved" in July IIRC 14:40:07 quaid: puts it on the SIG page 14:40:20 I don't mind putting it there, I just thought the board handled that kind of thing once they approved something. 14:40:40 #action jzb to put SIG proposal up on 14:40:40 [jzb] haven't heard back from him since last week, 14:40:43 sorry 14:40:49 quaid: heh 14:40:52 ok, added to http://wiki.centos.org/SpecialInterestGroup 14:41:40 typically, its been added there once the SIG is approved 14:42:31 OK 14:42:47 so next thing 14:42:50 jzb you have wiki edit privs? 14:42:53 there is no one listed as SIG chair 14:42:59 is this the proposal that got approved ??? 14:43:21 there are actully no members listed at all 14:43:29 kbsingh: what? 14:43:36 http://wiki.centos.org/SpecialInterestGroup/Atomic 14:43:45 The steering committee will consist initially of Joe Brockmeier, Jason Brooks, Jim Perrin, Brian Proffitt, and Greg DeKoenigsberg. 14:43:48 kbsingh: ^^ 14:43:48 looking at the http://wiki.centos.org/SpecialInterestGroup/Atomic page 14:44:08 humm 14:44:12 ok, lets fix that next 14:44:19 So it does say there that the committee will appt a chair 14:44:37 #action committee needs to appoint a chair 14:45:18 #action remaining committee members need to join centos-docs to request wiki access 14:45:38 quaid: sorry, to answer earlier question, yes. I do. 14:46:22 ok, so - having the names of folks in a wiki format means that moin can parse it and in the future, would be simpler to allocalte ACL's down 14:46:38 I've just done that here ( was looking for a list, which is why i didnt see any names ) 14:47:03 in the absense of a chair - Evolution should be able to request the git repo at bugs.centos.org/ against buildsys project 14:47:58 also, in the absence of a chair - he can do acl's but i highly recommend the sig appoint someone 14:48:30 kbsingh: OK, we'll do that this week. 14:48:50 jbrooks: i presume you want a repo like this : https://github.com/CentOS/sig-cloud-instance-build 14:49:15 jbrooks: if we can set it up so its a submodule of the instance-build, it would make building stuff easier ( long term, once we have that sorted out ) 14:49:47 kbsingh, Great, yes -- we just need a place where we can collaborate on what's in the images 14:50:01 ( [A]gree / [D]isagree / [N]ocomment ): 14:50:08 ok 14:50:18 kbsingh: ? 14:50:30 #info having the SIG build be a submodule of the instance-build would make building things easier in the long-term 14:50:36 i meant about setting it up so it can be consumed under the instance-build 14:50:55 kbsingh, Is that the system you used to build your test image? 14:50:55 can you link to more information about what instance-build is? 14:51:07 * jbrooks nods, doesn't know what instance-build is 14:51:18 its just that git repo 14:51:56 how stuff works at this point is that there is a beanstalkd which does queue management 14:52:05 the instance build queues map to that git repo 14:52:56 each dir name in there maps to a worker thread ( that might be running in a VM, or a baremetal box ) - at the moment, they all run on one machine, except the atomic one ( since it needs a c7 host ) 14:53:49 ah, ok 14:54:16 so its possible to do shell scripts etc, to do the builds, whatever comes out of the other end gets pushed to a private rsync 14:54:19 that can be anywhere 14:55:17 how will we manage the code that reacts to the beanstalk message? 14:55:31 the one thing that this does not factor into is the environment - we need to set that up either by hand or puppet or ansible or something 14:56:02 at the moment i've still been landing improvements to rpm-ostree-toolbox, but for fedora we've been working on a new anaconda/lorax bit that is in the process of being packaged 14:56:23 (depends on new anaconda, which i have an update on when we get there) 14:56:34 walters: good question, i can document that; its just a case of having a single executeable shell script that exit's 0 14:57:06 if we can get the git repo up, then next time we meet, I can do a walk through and demo a build start to finish 14:57:37 that'd be cool 14:57:49 also, at some point when this whole thing is stable ( from the centos and atomic side ) - we will be able to get SIG people actually onto the builder nodes as well - i have no idea how that might work though, but its in the agenda 14:57:58 That'd be great. Now, to go from test image to something like an alpha, I'd say we need to figure out signing and a update repo location 14:58:19 should we just talk organically here now, or are we sticking with agenda ? 14:58:42 jzb, get us on track? 14:58:43 re: signing - I've stubbed out rpm-sign, which uses a local key. 14:58:46 kbsingh: I'm fine with going organically if we're solving problems. 14:59:04 kbsingh: I don't stand on ceremony, I just want this to get out the door. :-) 14:59:21 the signing services for centos are hosted privately, and its non-trivial to get multiple files over - however since its only the checksums and its a detached sig - we might be able to do something 14:59:50 one thought was being able to stop the build when it comes to signing, ship the content off, get it signed, ship it back, shoehorn it back in and resume build 15:00:02 however, that means we need human intervention at sign stage 15:00:30 i went into that to demonstrate pain involved 15:00:45 could just sign before doing the sync, no? 15:00:51 what i recommend we do for now is to setup a local nssdb on the machine, and use a real rpm-sign process that consumes a local'ish key 15:01:40 walters: right, the challenge is letting the worker know its good to carry on 15:02:30 let me do this as a question : do we care and how much, if at all, that the key used to sign the content is the real distro key 15:02:56 imho, i think thats a good goal to have eventually, but short term we should just use something created for purpose, and keep it local 15:03:05 kbsingh: I think we're OK if it's a specific key for Atomic 15:03:08 It could be a sig-specific key, I think? 15:03:16 does anybody have an issue w/that? We can ask on list. 15:03:26 #action jzb survey on whether an Atomic Key is OK. 15:03:29 just do put the main key in /usr/share/ostree/trusted.gpg.d now too, so that when the transition happens the client will already trust it 15:03:34 IIRC we've said informally we're OK w/it. 15:03:38 there might be a TM issue there, but we can work that orthogonally 15:03:47 kbsingh: TM issue? 15:03:59 kbsingh: from using CentOS or Atomic? 15:04:09 (or do you not mean "trademark"?) 15:04:29 yeah, there is this thing about not being able to call it CentOS if the content isnt signed by one of the CentOS keyes 15:04:40 but in this case, i would assume its a centos sig key, so its centos 15:05:12 kbsingh: precisely - it wouldn't be used elsewhere, etc. 15:05:19 ( but, i am sure we can work that - its an issue we need to resolve for every sig ) - not something we need to work on / spend time on here now 15:05:46 walters: jbrooks: would rpm-sign then also be included in the git repo ? 15:05:58 the actual binary / script that gets called ? 15:08:02 .. 15:08:08 walters? 15:08:10 jbrooks: ? 15:08:20 so, next step is to have Evolution or SIG Chair request a build tag 15:08:32 something like atomicsig or sigatomic 15:08:39 sorry, If it's required to build the images / trees, I'd say yes -- I don't understand how that part works at this point 15:08:54 vs the fedora atomic initiative images, for instance 15:09:04 post that to the bugs.centos.org under buildsys as well - and Thomas will setup the koji targets + tags for that - this will also end up being the default branchname in git repos 15:09:09 Evolution: would you mind making the build tag req in the meantime? 15:09:39 can do. 15:09:55 then finally, once the tag is setup - we need one more request on bugs.centos.org with the srpms that need to be imported into git.centos.org/ 's rpms store - 15:10:37 #action Evolution request build tag per KB's info 15:10:44 at this point you can also request koji certs for people who are going to be doing builds, ideally try and keep that number low - since were doing lots of kludges and building legacy around the lack of a central auth setup 15:11:04 * jbrooks put in a cbs req last week 15:11:08 kbsingh: is 2-4 people low enough? 15:11:33 jzb: 2 ideally I'd think. 15:11:38 with the koji certs you should be able to hit the git repos, churn them into rpms, use the build-instance stuff to generate images. the only 2 things that we then need is the gather/scatter ( release parts ) and the announcements parts. 15:12:01 btw, I would also recommend getting an Atomic specific project at bugs.centos.org - either that, or request a 'atomic' component added to CentOS-7 15:12:07 that way you can get bugreports too! 15:12:23 +1 15:12:32 who wants to 'own' that project? 15:12:35 jbrooks: i think thats still hanging - Thomas didnt know what distro / sig and what tag etc 15:12:41 Evolution: not me :) 15:12:42 Evolution: what does that entail? 15:12:50 jzb: getting all the bugs 15:12:51 jzb: being responsible for bugs people file 15:12:52 Evolution: and what's involved in handing it off 15:13:07 btw, have a chat about it first - do you really want an entire project, or is an atomic component enough in CentOS-7 project 15:13:15 Evolution: temporarily, me. Then (hopefully) a person to be named very soon. 15:13:28 if you have Atomic as project, you can have components like os-tree and aws and things like that 15:13:29 jzb: an account on bugs.centos. and a few minutes of time to set it up. 15:13:47 kbsingh: If we get a bug that's really in CentOS how hard would it be to move from a separate project? 15:14:11 kbsingh: e.g., if someone reports a bug in the kernel that exists in CentOS independently, if we're a component it's easy to reassign, right? 15:14:12 jzb: reasonably painless. we do that already. 15:14:28 we have people reporting stuff for 6 in 7 and vice versa. 15:14:31 Evolution: OK. Let's discuss on list, but I don't know if it makes a huge difference. 15:14:45 sure. 15:14:46 there are no bugs in CentOS! 15:14:58 they are just features that folks havent quite worked out howto consume best 15:15:01 #action jzb open discussion on how Atomic should be listed in bugs.centos.org 15:15:07 kbsingh: +1 15:15:12 well played kbsingh 15:15:15 kbsingh: but they still *think* they're bugs & report them. 15:16:10 OK, what's next? 15:16:40 I think all of the above should get you guys set on the execution front - the next big thing is what it is that we want to execute 15:16:53 i think walters had some content re: image building/anaconda and future of that 15:16:58 and bexelbie had some scope content ? 15:17:11 hi, sorry i have to dual meeting 15:17:17 so the basic thing i wanted to mention was http://copr.fedoraproject.org/coprs/rvykydal/anaconda-el7-atomic/ 15:17:34 I have some material on using Atomic that could be used with CentOS Atomic as documentation if there is interest 15:17:45 It would be a base we could build on 15:17:57 but it sounds like we don't yet have an image to use it against 15:18:22 walters: that might make for an awesome first-list-of-srpms to import and build - is that functional ? 15:18:33 if so, we might not need to worry about the -toolbox thing at all 15:18:37 kbsingh, it's still a work in progress 15:18:40 just bootstrap with the anaconda 15:18:55 most notably, there's a backport of 7.1-proposed systemd 15:19:35 the SIG has capacity to deliver overlapping and forward looking packages... 15:19:44 its upto the SIG to decide if thats what we want to do here 15:20:12 so if you think thats the way to go - we can certainly try that 15:20:16 walters, And the newer anaconda is mainly needed for the bare metal installer? 15:20:25 yes 15:20:50 Ok, maybe that's one to discuss on the list? 15:22:56 I'd skip the baremetal for now 15:23:21 kbsingh, so first target would be VM? 15:23:28 kbsingh, the intersection is that anaconda is a better long term tool for generating disk images (like the cloud one) than -toolbox 15:23:41 yup, i agree :) 15:23:49 but what do we want out there now 15:23:50 We could actually use the fedora installer and then use rpm-ostree to switch to centos, if needed 15:24:14 jbrooks: +1 on linst 15:24:16 list 15:24:25 (sorry, also dual-meeting'ing. 15:24:27 lets assume we want an atomic tree, built from centos, usable and releaseable as a beta by the 1st October 15:24:29 That's clunky, but if ppl were dying to bare metal out of the gate 15:24:30 what would we do there 15:24:33 jbrooks, that almost sounds rude :P 15:25:03 kbsingh, We'll need a stable update repo location 15:25:27 jbrooks: right 15:25:39 this isnt cloud specific, so we can put that on dev.centos.org or something such 15:25:54 we can even put it on buildlogs.centos.org - which has lots of b/w and hardly any usage at the moment 15:26:58 That should be fine 15:27:34 w/ the configs available, a bug tracker in place, builds and updates -- we'll be set for testers 15:28:09 cool 15:28:20 bexelbie: what sort of docs do you have ? 15:28:35 kbsingh, overview of atomic and basic system administration 15:28:41 the hows and whys 15:28:44 in quick form 15:29:05 if we go VM first on install, I can probably include some information on how to install it with qemu if needed 15:29:47 * bexelbie also had to dual meeting for parts of this, "Do we have a build date for an atomic image?" 15:30:17 "atomic status" will show you the commit timestamps 15:30:58 bexelbie: I think kbsingh just committed to 1 October. ;-) 15:31:02 we can keep talking but kbsingh Evolution & I are joining a voice/video call at the same time now 15:31:14 jzb, ty - I missed that line somewhere in my reading 15:31:17 do we want to adjourn for now and sync up again? 15:31:22 I'm on another irc meeting re: dojos in the far east as well - but will try and keep up 15:31:25 I think most of us are being called away. 15:31:35 bexelbie: i think docs are good - they would give us a target feature set to hit as well 15:31:45 I think we need to bring the Anaconda conversation to the list? 15:31:56 kbsingh, shall I ask for wiki access or do we host our docs somewhere else? 15:31:56 walters: ^^ ? 15:32:01 (Anaconda) 15:32:02 bexelbie: would wiki.centos.org be a place to host them ? then the entire sig memberlist can edit / parse etc 15:32:18 kbsingh, that can work - I want to follow community standards 15:32:18 bexelbie: CentOS Atomic SIG on wiki. 15:32:24 i'll post on atomic-devel about the anaconda backport work 15:32:25 bexelbie: so please go there, yeah. 15:32:33 we can always move them later if appropriate 15:32:35 jzb: yes, lets do the anaconda convo on the list - but from what i can tell, it might be best to kick off with ostree-toolbox for now, and work with anaconda in the background 15:32:41 #action walters to post on atomic-devel on Anaconda work 15:32:48 kbsingh: OK 15:32:49 sounds good 15:33:11 any other items we want to tackle before closing meeting, seeing as 1/2 to 2/3rds are in other meetings? 15:33:12 :-) 15:33:30 and I am finally back to single-meeting 15:33:34 quick someone send me an invite :P 15:33:47 bexelbie: be careful what you wish for ;-) 15:33:50 :) 15:33:51 heh 15:33:57 jzb, I think we've got a good start 15:34:01 Yep 15:34:08 OK, let's go forth and do good things. 15:34:13 #endmeeting