14:31:32 <jzb> #startmeeting CentOS SIG
14:31:32 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:31:32 <centbot> 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 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:31:36 <kbsingh> there are a bunch of other things going on as well, tying to close those down
14:32:31 <jzb> OK, let's get started
14:32:37 <jzb> so - I didn't receive any other agenda items
14:32:51 <jzb> first things I had on the agenda were
14:33:00 <jzb> * request for a git repository on git.centos.org
14:33:13 <jzb> * access to JSON files & build system that's been used so far for builds.
14:33:21 <jzb> any other items this week?
14:33:34 <quaid> jzb: can you share #chair?
14:33:43 <jzb> No! Mine!
14:33:47 <jzb> Yes, hang on
14:34:08 <jzb> #chair quaid kbsingh jbrooks walters
14:34:08 <zodbot> Current chairs: jbrooks jzb kbsingh quaid walters
14:34:08 <centbot> Current chairs: jbrooks jzb kbsingh quaid walters
14:34:15 <walters> * build locations and sources
14:34:16 <jzb> quaid: sorry 'bout that. too early.
14:34:19 <quaid> #topic Agenda
14:34:30 <quaid> #info request for a git repository on git.centos.org
14:34:39 <quaid> #info access to JSON files & build system that's been used so far for builds.
14:34:41 * bexelbie is here
14:34:47 <jzb> #chair bexelbie
14:34:47 <zodbot> Current chairs: bexelbie jbrooks jzb kbsingh quaid walters
14:34:47 <centbot> Current chairs: bexelbie jbrooks jzb kbsingh quaid walters
14:34:48 <quaid> #info build locations and sources
14:35:09 <jzb> a pony and some cotton candy...
14:35:14 * jzb worth a shot.
14:35:34 <kbsingh> is Ian here ?
14:35:43 <kbsingh> no..
14:35:52 <quaid> I just realized 5 min ago we didn't invite him, just asked him on IRC
14:36:02 <kbsingh> so, what do we want to put in that git repo on git.centos.org
14:36:08 <walters> where's the git repo?
14:36:13 <quaid> #topic git repo
14:36:43 <jbrooks> kbsingh, the json files, anything else required to compose the tree
14:37:36 <jzb> jbrooks: would we keep packages there that aren't in official CentOS?
14:37:42 <jzb> or those sources elsewhere?
14:37:58 <jbrooks> I don't know -- how are other sigs doing it?
14:37:59 <kbsingh> so, something like bld-cloud-instance...
14:38:07 <kbsingh> who's listed as the SIG chair ?
14:38:23 <kbsingh> http://wiki.centos.org/SpecialInterestGroup
14:38:24 <kbsingh> well
14:38:30 <kbsingh> step-1, get the SIG proposal online
14:38:46 <jbrooks> http://lists.centos.org/pipermail/centos-devel/2014-June/011225.html
14:38:47 <jzb> http://wiki.centos.org/SpecialInterestGroup/Atomic
14:38:52 <jzb> kbsingh: it's been online
14:39:23 <jbrooks> I thought it was approved, too? Maybe not yet
14:39:25 <kbsingh> it needs to be on the SIG's page, in an appropriate section
14:39:44 <jzb> kbsingh: just out of curiosity, who does that?
14:39:52 <quaid> does which?
14:39:56 <jzb> kbsingh: b/c it was "approved" in July IIRC
14:40:07 <jzb> quaid: puts it on the SIG page
14:40:20 <jzb> I don't mind putting it there, I just thought the board handled that kind of thing once they approved something.
14:40:40 <quaid> #action jzb to put SIG proposal up on
14:40:40 <quaid> [jzb] haven't heard back from him since last week,
14:40:43 <quaid> sorry
14:40:49 <jzb> quaid: heh
14:40:52 <kbsingh> ok, added to http://wiki.centos.org/SpecialInterestGroup
14:41:40 <kbsingh> typically, its been added there once the SIG is approved
14:42:31 <jzb> OK
14:42:47 <kbsingh> so next thing
14:42:50 <quaid> jzb you have wiki edit privs?
14:42:53 <kbsingh> there is no one listed as SIG chair
14:42:59 <kbsingh> is this the proposal that got approved ???
14:43:21 <kbsingh> there are actully no members listed at all
14:43:29 <jzb> kbsingh: what?
14:43:36 <jbrooks> http://wiki.centos.org/SpecialInterestGroup/Atomic
14:43:45 <jzb> The steering committee will consist initially of Joe Brockmeier, Jason Brooks, Jim Perrin, Brian Proffitt, and Greg DeKoenigsberg.
14:43:48 <jzb> kbsingh: ^^
14:43:48 <kbsingh> looking at the http://wiki.centos.org/SpecialInterestGroup/Atomic page
14:44:08 <kbsingh> humm
14:44:12 <kbsingh> ok, lets fix that next
14:44:19 <jbrooks> So it does say there that the committee will appt a chair
14:44:37 <quaid> #action committee needs to appoint a chair
14:45:18 <quaid> #action remaining committee members need to join centos-docs to request wiki access
14:45:38 <jzb> quaid: sorry, to answer earlier question, yes. I do.
14:46:22 <kbsingh> 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 <kbsingh> I've just done that here ( was looking for a list, which is why i didnt see any names )
14:47:03 <kbsingh> 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 <kbsingh> also, in the absence of a chair - he can do acl's but i highly recommend the sig appoint someone
14:48:30 <jzb> kbsingh: OK, we'll do that this week.
14:48:50 <kbsingh> jbrooks: i presume you want a repo like this : https://github.com/CentOS/sig-cloud-instance-build
14:49:15 <kbsingh> 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 <jbrooks> kbsingh, Great, yes -- we just need a place where we can collaborate on what's in the images
14:50:01 <kbsingh> ( [A]gree / [D]isagree / [N]ocomment ):
14:50:08 <kbsingh> ok
14:50:18 <jzb> kbsingh: ?
14:50:30 <quaid> #info having the SIG build be a submodule of the instance-build would make building things easier in the long-term
14:50:36 <kbsingh> i meant about setting it up so it can be consumed under the instance-build
14:50:55 <jbrooks> kbsingh, Is that the system you used to build your test image?
14:50:55 <walters> 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 <kbsingh> its just that git repo
14:51:56 <kbsingh> how stuff works at this point is that there is a beanstalkd which does queue management
14:52:05 <kbsingh> the instance build queues map to that git repo
14:52:56 <kbsingh> 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 <walters> ah, ok
14:54:16 <kbsingh> 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 <kbsingh> that can be anywhere
14:55:17 <walters> how will we manage the code that reacts to the beanstalk message?
14:55:31 <kbsingh> 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 <walters> 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 <walters> (depends on new anaconda, which i have an update on when we get there)
14:56:34 <kbsingh> 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 <kbsingh> 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 <walters> that'd be cool
14:57:49 <kbsingh> 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 <jbrooks> 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 <kbsingh> should we just talk organically here now, or are we sticking with agenda ?
14:58:42 <jbrooks> jzb, get us on track?
14:58:43 <kbsingh> re: signing - I've stubbed out rpm-sign, which uses a local key.
14:58:46 <jzb> kbsingh: I'm fine with going organically if we're solving problems.
14:59:04 <jzb> kbsingh: I don't stand on ceremony, I just want this to get out the door. :-)
14:59:21 <kbsingh> 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 <kbsingh> 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 <kbsingh> however, that means we need human intervention at sign stage
15:00:30 <kbsingh> i went into that to demonstrate pain involved
15:00:45 <walters> could just sign before doing the sync, no?
15:00:51 <kbsingh> 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 <kbsingh> walters: right, the challenge is letting the worker know its good to carry on
15:02:30 <kbsingh> 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 <kbsingh> 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 <jzb> kbsingh: I think we're OK if it's a specific key for Atomic
15:03:08 <jbrooks> It could be a sig-specific key, I think?
15:03:16 <jzb> does anybody have an issue w/that? We can ask on list.
15:03:26 <jzb> #action jzb survey on whether an Atomic Key is OK.
15:03:29 <walters> 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 <jzb> IIRC we've said informally we're OK w/it.
15:03:38 <kbsingh> there might be a TM issue there, but we can work that orthogonally
15:03:47 <jzb> kbsingh: TM issue?
15:03:59 <jzb> kbsingh: from using CentOS or Atomic?
15:04:09 <jzb> (or do you not mean "trademark"?)
15:04:29 <kbsingh> 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 <kbsingh> but in this case, i would assume its a centos sig key, so its centos
15:05:12 <jzb> kbsingh: precisely - it wouldn't be used elsewhere, etc.
15:05:19 <kbsingh> ( 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 <kbsingh> walters: jbrooks: would rpm-sign then also be included in the git repo ?
15:05:58 <kbsingh> the actual binary / script that gets called ?
15:08:02 <kbsingh> ..
15:08:08 <jzb> walters?
15:08:10 <jzb> jbrooks: ?
15:08:20 <kbsingh> so, next step is to have Evolution or SIG Chair request a build tag
15:08:32 <kbsingh> something like atomicsig or sigatomic
15:08:39 <jbrooks> 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 <jbrooks> vs the fedora atomic initiative images, for instance
15:09:04 <kbsingh> 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 <jzb> Evolution: would you mind making the build tag req in the meantime?
15:09:39 <Evolution> can do.
15:09:55 <kbsingh> 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 <jzb> #action Evolution request build tag per KB's info
15:10:44 <kbsingh> 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 <jzb> kbsingh: is 2-4 people low enough?
15:11:33 <Evolution> jzb: 2 ideally I'd think.
15:11:38 <kbsingh> 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 <kbsingh> 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 <kbsingh> that way you can get bugreports too!
15:12:23 <jbrooks> +1
15:12:32 <Evolution> who wants to 'own' that project?
15:12:35 <kbsingh> jbrooks: i think thats still hanging - Thomas didnt know what distro / sig and what tag etc
15:12:41 <kbsingh> Evolution: not me :)
15:12:42 <jzb> Evolution: what does that entail?
15:12:50 <kbsingh> jzb: getting all the bugs
15:12:51 <Evolution> jzb: being responsible for bugs people file
15:12:52 <jzb> Evolution: and what's involved in handing it off
15:13:07 <kbsingh> 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 <jzb> Evolution: temporarily, me. Then (hopefully) a person to be named very soon.
15:13:28 <kbsingh> if you have Atomic as project, you can have components like os-tree and aws and things like that
15:13:29 <Evolution> jzb: an account on bugs.centos. and a few minutes of time to set it up.
15:13:47 <jzb> 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 <jzb> 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 <Evolution> jzb: reasonably painless. we do that already.
15:14:28 <Evolution> we have people reporting stuff for 6 in 7 and vice versa.
15:14:31 <jzb> Evolution: OK. Let's discuss on list, but I don't know if it makes a huge difference.
15:14:45 <Evolution> sure.
15:14:46 <kbsingh> there are no bugs in CentOS!
15:14:58 <kbsingh> they are just features that folks havent quite worked out howto consume best
15:15:01 <jzb> #action jzb open discussion on how Atomic should be listed in bugs.centos.org
15:15:07 <jzb> kbsingh: +1
15:15:12 <bexelbie> well played kbsingh
15:15:15 <jzb> kbsingh: but they still *think* they're bugs  & report them.
15:16:10 <jzb> OK, what's next?
15:16:40 <kbsingh> 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 <kbsingh> i think walters had some content re: image building/anaconda and future of that
15:16:58 <kbsingh> and bexelbie had some scope content ?
15:17:11 <walters> hi, sorry i have to dual meeting
15:17:17 <walters> so the basic thing i wanted to mention was http://copr.fedoraproject.org/coprs/rvykydal/anaconda-el7-atomic/
15:17:34 <bexelbie> I have some material on using Atomic that could be used with CentOS Atomic as documentation if there is interest
15:17:45 <bexelbie> It would be a base we could build on
15:17:57 <bexelbie> but it sounds like we don't yet have an image to use it against
15:18:22 <kbsingh> walters: that might make for an awesome first-list-of-srpms to import and build - is that functional ?
15:18:33 <kbsingh> if so, we might not need to worry about the -toolbox thing at all
15:18:37 <walters> kbsingh, it's still a work in progress
15:18:40 <kbsingh> just bootstrap with the anaconda
15:18:55 <walters> most notably, there's a backport of 7.1-proposed systemd
15:19:35 <kbsingh> the SIG has capacity to deliver overlapping and forward looking packages...
15:19:44 <kbsingh> its upto the SIG to decide if thats what we want to do here
15:20:12 <kbsingh> so if you think thats the way to go - we can certainly try that
15:20:16 <jbrooks> walters, And the newer anaconda is mainly needed for the bare metal installer?
15:20:25 <walters> yes
15:20:50 <jbrooks> Ok, maybe that's one to discuss on the list?
15:22:56 <kbsingh> I'd skip the baremetal for now
15:23:21 <bexelbie> kbsingh, so first target would be VM?
15:23:28 <walters> 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 <kbsingh> yup, i agree :)
15:23:49 <kbsingh> but what do we want out there now
15:23:50 <jbrooks> We could actually use the fedora installer and then use rpm-ostree to switch to centos, if needed
15:24:14 <jzb> jbrooks: +1 on linst
15:24:16 <jzb> list
15:24:25 <jzb> (sorry, also dual-meeting'ing.
15:24:27 <kbsingh> lets assume we want an atomic tree, built from centos, usable and releaseable as a beta by the 1st October
15:24:29 <jbrooks> That's clunky, but if ppl were dying to bare metal out of the gate
15:24:30 <kbsingh> what would we do there
15:24:33 <bexelbie> jbrooks, that almost sounds rude :P
15:25:03 <jbrooks> kbsingh, We'll need a stable update repo location
15:25:27 <kbsingh> jbrooks: right
15:25:39 <kbsingh> this isnt cloud specific, so we can put that on dev.centos.org or something such
15:25:54 <kbsingh> 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 <jbrooks> That should be fine
15:27:34 <jbrooks> w/ the configs available, a bug tracker in place, builds and updates -- we'll be set for testers
15:28:09 <kbsingh> cool
15:28:20 <kbsingh> bexelbie: what sort of docs do you have ?
15:28:35 <bexelbie> kbsingh, overview of atomic and basic system administration
15:28:41 <bexelbie> the hows and whys
15:28:44 <bexelbie> in quick form
15:29:05 <bexelbie> 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 <walters> "atomic status" will show you the commit timestamps
15:30:58 <jzb> bexelbie: I think kbsingh just committed to 1 October. ;-)
15:31:02 <quaid> we can keep talking but kbsingh Evolution & I are joining a voice/video call at the same time now
15:31:14 <bexelbie> jzb, ty - I missed that line somewhere in my reading
15:31:17 <jzb> do we want to adjourn for now and sync up again?
15:31:22 <kbsingh> I'm on another irc meeting re: dojos in the far east as well - but will try and keep up
15:31:25 <jzb> I think most of us are being called away.
15:31:35 <kbsingh> bexelbie: i think docs are good - they would give us a target feature set to hit as well
15:31:45 <jzb> I think we need to bring the Anaconda conversation to the list?
15:31:56 <bexelbie> kbsingh, shall I ask for wiki access or do we host our docs somewhere else?
15:31:56 <jzb> walters: ^^ ?
15:32:01 <jzb> (Anaconda)
15:32:02 <kbsingh> bexelbie: would wiki.centos.org be a place to host them ? then the entire sig memberlist can edit / parse etc
15:32:18 <bexelbie> kbsingh, that can work - I want to follow community standards
15:32:18 <jzb> bexelbie: CentOS Atomic SIG on wiki.
15:32:24 <walters> i'll post on atomic-devel about the anaconda backport work
15:32:25 <jzb> bexelbie: so please go there, yeah.
15:32:33 <bexelbie> we can always move them later if appropriate
15:32:35 <kbsingh> 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 <jzb> #action walters to post on atomic-devel on Anaconda work
15:32:48 <jzb> kbsingh: OK
15:32:49 <kbsingh> sounds good
15:33:11 <jzb> any other items we want to tackle before closing meeting, seeing as 1/2 to 2/3rds are in other meetings?
15:33:12 <jzb> :-)
15:33:30 <bexelbie> and I am finally back to single-meeting
15:33:34 <bexelbie> quick someone send me an invite :P
15:33:47 <jzb> bexelbie: be careful what you wish for ;-)
15:33:50 <jbrooks> :)
15:33:51 <bexelbie> heh
15:33:57 <jbrooks> jzb, I think we've got a good start
15:34:01 <jzb> Yep
15:34:08 <jzb> OK, let's go forth and do good things.
15:34:13 <jzb> #endmeeting