16:00:05 <jzb> #startmeeting CentOS Atomic SIG
16:00:05 <centbot> Meeting started Thu Mar 19 16:00:05 2015 UTC.  The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:05 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:07 <Evolution> jzb: getting a new alarm system wired in the house.
16:00:13 <Evolution> might be distracted at times
16:00:22 <jzb> #chair Evolution jbrooks imcleod walters kbsingh
16:00:22 <centbot> Current chairs: Evolution imcleod jbrooks jzb kbsingh walters
16:00:35 <jzb> last week's AIs
16:01:06 <jzb> jbrooks create stable release checklist
16:01:16 <jzb> #topic create release checklist
16:01:19 <jzb> jbrooks: how's that going?
16:01:49 <jbrooks> Good -- just a few items, I'd say
16:01:54 <jbrooks> And some things to talk about
16:02:20 <jzb> jbrooks: talk about now or take to the list?
16:02:24 <jbrooks> Like the image signing and serving via https -- fedora doesn't do either of those
16:02:28 <jzb> jbrooks: can you maybe start the checklist on the wiki?
16:02:34 <jbrooks> Don't know if we want to gate on that or not
16:02:52 <jbrooks> jzb, sure
16:03:19 <jbrooks> But the main thing is settling on our policy for updates -- when do we want to update our cbs-built pkgs
16:03:35 <jbrooks> Like we're on k8s .9, f21 is on .11
16:03:49 <jzb> when they're ready?
16:04:03 * jzb wishes we had a release manager.
16:04:10 <jbrooks> Well, are we even attempting to build a newer k8s?
16:04:30 <jzb> jbrooks: aren't we pulling k8s from the cloud sig currently?
16:04:49 <jbrooks> it's the virt-sig, I think?
16:04:49 <jzb> right now we've been standing on their shoulders
16:04:55 <jzb> oh, sorry - virt-sig
16:04:57 <jzb> yes
16:05:03 <jbrooks> So maybe that's an item to take up w/ them
16:05:07 <jzb> at any rate - "we" haven't been doign it.
16:05:28 <jbrooks> But in order to go "stable" we need to settle how we're moving forward on these pkg updates
16:05:41 <jbrooks> And testing is the other item
16:05:57 <jbrooks> That's if we want to wait on the security items, as fedora has done
16:06:25 <jbrooks> I'd like to see us go stable shortly after centos 7-1503 is out
16:06:37 <imcleod> jbrooks: +1
16:06:55 <jbrooks> But, on the gpg signing and https update repo, maybe we should discuss that a bit?
16:07:08 <jzb> jbrooks: sure
16:07:10 <imcleod> Quick note that we have at least the start of the CBS setup for this.  There are virt7-release and atomic7-release tags (both currently empty).
16:07:28 <walters> note a big improvement to ostree-gpg landed recently https://github.com/GNOME/ostree/pull/77
16:07:41 * lalatenduM is late to the meeting
16:07:49 <jzb> #chair lalatenduM
16:07:49 <centbot> Current chairs: Evolution imcleod jbrooks jzb kbsingh lalatenduM walters
16:09:06 <jbrooks> Getting the signing in place seems important to me, but I suppose it depends on how long that will take to get straight. And do we sign w/ a centos key, or a new atomic sig key?
16:09:51 <jzb> I would like to have this signed. Theoretically this is not just something people will use on their laptop for plinking about with one or two containers.
16:10:23 <jzb> we should go with the expectation that people want to verify where their bits come from.
16:10:42 <jbrooks> Do we know what's held Fedora back from signing?
16:11:16 * kbsingh here, catching up
16:11:44 <walters> jbrooks, a (imo broken) requirement on inline versus detached signatures
16:12:00 <jbrooks> walters, And that's a fedora requirement?
16:12:26 <walters> right
16:12:37 <walters> with no public written rationale
16:13:00 <jbrooks> walters, How do you think we should proceed on this?
16:13:06 <kbsingh> w.r.t signing, if we can get the underlyaing rpms signed, I'll do whtever is needed. however its needed to sign ostree commit as well
16:13:11 <walters> anyways i'm planning a potential change to how signatures work, which would also allow working around this https://mail.gnome.org/archives/ostree-list/2015-February/msg00004.html
16:13:33 <walters> basically sign the toplevel metadata, just like how yum supports signing the repomd
16:14:12 <kbsingh> w.r.t https:// its harder, since we then need to lock down the hostname, and get the ca certs into the client, or use something publicly verifyable, maybe an EV Code cert. that makes life slightly harder, since its not just gpg involved.
16:14:13 <walters> (I actually think all distros should prefer repomd signing over rpm signing personally, the authors of theupdateframework.com have a paper on why)
16:14:28 <jbrooks> Should we vote on gating our stable release on signing? I'm +1 if it doesn't take too long to put in place.
16:15:02 <kbsingh> walters: i sort of agree, except most downstream at-scale folks rebuilding repomd, so not signing content does not seem like a good play - signing repomd at the distro level certainly is a good thing ( and is on the radar for Apr 2015 for centos.org )
16:15:27 <kbsingh> jbrooks: +1 for signing all content before its called stable
16:15:54 <kbsingh> walters: so i am reading this right, fedora wants the sig to be inline ???
16:16:01 <walters> correct
16:16:13 <walters> the ostree signature design is detached to allow a binary-level promotion model
16:16:32 <walters> you have a dev tree, signed with the dev key.  Passes tests, signed by QE key.  Ready to ship, signed with gold key
16:17:33 <jzb> jbrooks: I'm also +1 on signing for stable.
16:17:40 <jzb> and preferably https as well.
16:17:58 <jbrooks> OK, I think we should have a lead on getting signing squared away
16:18:46 <jzb> imcleod: would that be you?
16:19:09 <imcleod> jzb: Sure.  I'll have at it.
16:19:29 <imcleod> jzb: Be warned, my handwriting is horrible, so they may not be legible signatures.
16:19:36 <jzb> heh
16:19:52 <lalatenduM> do we have access to the infra for fixing the signing stuff
16:19:54 <jzb> #action imcleod take lead on getting signing ready for imminent "stable" release
16:19:55 <walters> kbsingh, that's a good point about the repomd regeneration, I hadn't considered that.  Of course OTOH, anyone with the ability to add new RPMs has the ability to own the machine and change e.g. the kernel package and the gpg binary to print out "GOODSIG"
16:20:27 <jbrooks> jzb, Is fedora further along in their 2 week release cycle plans, far enough that we can plan to follow them for our cbs-built packages?
16:20:30 <imcleod> kbsingh: Will need to chat with you about how the existing signing infra works and how content should pass through it.  I gather it is, for obvious reasons, very tightly controlled.
16:20:48 <kbsingh> walters: I am all for detached sig's :)
16:21:03 <jzb> jbrooks: ish
16:21:13 <kbsingh> imcleod: sort of
16:21:23 <kbsingh> imcleod: there is a -testing key that can be (ab)used with low barriers.
16:21:27 <jzb> jbrooks: we should probably plan for that, it should not be horribly far away.
16:21:42 <jbrooks> jzb, Maybe you could take lead on that update-scheduling 2/4 bit, I can take point on the testing part
16:21:57 <jbrooks> I think those 3 things are the keys to stable
16:22:03 <kbsingh> we'd need to work the relatinship a bit to getting the virt-sig content signed as well, but should be easy - i think we know where lsm5 and gwd  live...
16:22:05 <walters> testing key makes sense to me
16:22:43 <jzb> #action jzb get final dates/info on two and four-week update plans.
16:22:45 <nzwulfin> /win 2
16:22:56 <jzb> I'm glad I'm not the only one who does that.
16:22:58 <nzwulfin> sry
16:23:22 <jzb> jbrooks: and you're going to start a doc on the wiki around this?
16:23:32 <jbrooks> jzb, yes, I will
16:23:36 <jzb> #action jbrooks document release checklist on the wiki
16:23:43 <jzb> anything else on this topic?
16:24:10 * jzb looks around
16:24:12 <jzb> OK
16:24:18 <kbsingh> so
16:24:22 <jzb> #topic Requirements for rebuild
16:24:24 <kbsingh> yes, but, no but, maybe
16:24:25 <lsm5> kbsingh: haven't done any package signing before, but let me know what I can do
16:24:42 <kbsingh> langdon: requested atomic content in /etc/os-release file
16:24:47 <jzb> kbsingh: sorry?
16:25:50 <kbsingh> http://bugs.centos.org/view.php?id=8288
16:25:54 <kbsingh> jzb: ^
16:26:21 <jzb> ah, OK
16:26:37 <jzb> how difficult is this? I'm guessing not insurmountable?
16:26:39 <kbsingh> so, this was in context of : what do we need for 'stable'
16:26:43 <kbsingh> is that something we need to get done ?
16:26:48 <kbsingh> its tricky
16:26:56 <kbsingh> os-release is shipped by centos-release.rpm
16:27:00 <jbrooks> it would help -- this isn't the only way to know you're on atomic, though
16:27:13 <jbrooks> you can look for /etc/ostree/remotes.d/...
16:27:27 <kbsingh> and isnt dynamic on the client side, its a text file that gets dropped in - and ideally, we dont want the users futzing around with it, so that updates can be shipped and code can rely on the updates being applied ( and not going to .rpmnew )
16:27:38 <walters> jbrooks, i'd prefer looking for read-only /usr over that
16:27:56 <lalatenduM> +1 for a release file
16:27:58 <kbsingh> I mount my containers read-only
16:28:21 <jzb> kbsingh: what about an /etc/atomic-release file?
16:28:47 <jbrooks> f21 doesn't mention atomic in its os-release
16:28:54 <kbsingh> jzb: sounds good. we have a centos-release-atomic.rpm at the moment, it can ship stuff. I guess it already does ship the remote ostree repo url.
16:28:55 <jzb> kbsingh: or can we simply have a different centos-release file?
16:29:03 <lalatenduM> I think release file is inline to how fedora and CentOS have , so it make sense
16:29:28 <kbsingh> jzb: its not the centos-release, its the os-release. diff being os-release has a bunch of things that any script can source, and ECHO $VERSION_ID ; etc
16:29:51 <kbsingh> c6 didnt have it, c7 does
16:29:58 <jzb> kbsingh: sorry, I meant different centos-release RPM
16:30:20 <kbsingh> stepping back, walters sort of changed the question a bit : can we put this flag in some other place ? if so, it makes life easier. if we cant, then we need to workout a plan
16:30:48 <kbsingh> if we can ship something else, for the tools to check against, and isnt a huge pain, then we can ship that flag via centos-release-atomic ( which requires: centos-release )
16:31:56 <jzb> OK, who wants to own this?
16:32:36 <lalatenduM> kbsingh, do we know what should go in to the release file?
16:32:43 <lalatenduM> what info*
16:33:18 <lalatenduM> jzb, you can put it on me
16:33:23 <jzb> OK, thanks
16:33:43 <jzb> #action lalatenduM atomic info in /etc/os-release: http://bugs.centos.org/view.php?id=8288
16:33:51 <jzb> lalatenduM: do you have an account on the CentOS bug tracker?
16:33:55 <jbrooks> It looks like rhel atomic puts this in /etc/os-release
16:33:58 <lalatenduM> jzb, yes
16:34:07 <lalatenduM> its lalatendumohanty
16:34:50 <lalatenduM> #info rhel atomic puts release file in /etc/os-release
16:35:01 <jzb> kbsingh: for some reason lalatenduM's account doesn't show up in "assign to"?
16:35:15 <jzb> is the Atomic product limited to certain accounts, or...?
16:35:19 <lalatenduM> jzb, yeah , as my role is reporter
16:35:24 <lalatenduM> in the bugzilla
16:35:54 <kbsingh> to add assign to: the user account needs to be marked as 'developer'
16:36:01 <kbsingh> ( i might be wrong, Evolution can confirm )
16:36:11 <jzb> kbsingh: can you or Evolution tag lalatenduM's account thusly?
16:36:36 <kbsingh> i am sure we can work it out
16:36:45 <Evolution> I'll take a look at it, yes.
16:36:48 <kbsingh> he likely needs it for the storage sig and atomic sig as well
16:36:59 <Evolution> if I can scope it to the projects required, I'm fine with it
16:37:16 <jzb> Evolution: cool, thanks
16:37:20 <jzb> OK, anything else on this?
16:37:20 <kbsingh> Evolution: wonder if we should just make all git accounts / koji account requests also get 'dev' for mantis in their own project ? ( no idea how easy that is or hard )
16:37:36 * kbsingh takes convo with Evolution elsewhere
16:38:01 <jzb> #topic back to Atomic rebuild
16:38:27 <jzb> imcleod: you had the action to scope this out, do we have an idea how hard it's going to be to try to rebuild 7.1 Atomic if we chose to do so?
16:39:17 <imcleod> jzb: I've done only minimal poking at that.  The base Atomic image should be relatively simple now that 7.1 is out and being worked through the CentOS core process.
16:39:58 <Evolution> seems I can. I've added lalatenduM in there
16:40:02 <jzb> imcleod: no missing pieces or anything that would be extremely difficult?
16:40:20 <imcleod> jzb: I suppose I should ask here if a "full rebuild" in includes anything beyond the base Atomic image and tree.  RHEL ships "tools" and "rsyslog" containers that formed part of the product release.
16:40:43 <Evolution> is there anyone else we'd want to be 'responsible' for tickets for atomic?
16:40:49 <imcleod> I'm not 100% clear if anything in "tools" would be relevant for CentOS.  It may have more to do with subscription management.  rsyslog might be worth looking at more closely.
16:40:58 <jzb> Evolution: anybody that will do the work? :-)
16:41:11 <Evolution> right now it's you and lalatenduM so...
16:41:21 <kbsingh> Evolution: send them to jzb
16:41:24 <kbsingh> he likes email
16:41:31 <Evolution> wfm
16:41:33 <imcleod> jzb: Based on my involvement leading up to the release, I don't think anything should be difficult.  We were able to produce something very much like the RHEL work a couple of months prior to the release.  We just need to re-sync.
16:41:41 <jzb> Evolution: imcleod and jbrooks if they aren't already
16:41:45 <imcleod> walters: Would you anticipate any show stoppers with that?
16:41:49 <jzb> Evolution: more to come
16:42:01 <jzb> imcleod: OK
16:42:03 <Evolution> imcleod: I *do* accept bribes if you don't want bugs....
16:42:07 <Evolution> just sayin
16:42:13 <jzb> Evolution: I read that as "hugs"
16:42:47 <jzb> imcleod: I think an rsyslog container would be good to have but is maybe not mandatory as part of a rebuild.
16:42:54 * imcleod gives Evolution a bottle of scotch to avoid a hug.....
16:43:07 <jzb> dang.
16:43:18 * jzb takes a note to start being huggier.
16:43:40 <jzb> #topic open floor
16:43:43 <jzb> any new topics this week?
16:43:47 <jzb> walters: ^^?
16:44:01 <walters> back, sorry
16:44:27 <walters> imcleod, tools is definitely relevant, it's a way to get e.g. strace
16:45:06 <walters> note that fedora doesn't have a tools container either yet, and that's a major item that needs doing
16:45:50 <walters> i had one other thing i wanted to mention, which is https://github.com/CentOS/sig-atomic-buildscripts/issues/18
16:45:52 <jzb> walters: is the Dockerfile public?
16:46:22 <walters> no, which is a rel-eng issue that needs to be sorted out; IMO RHEL should publish kickstarts and Dockerfiles for images
16:46:46 <jzb> walters: can we get those particular ones pushed public?
16:47:00 <kbsingh> as step-1, we dont need to match it, we just need something - and we can let community decide what features they want ( and help build them into these containers )
16:48:01 <walters> i think this needs to be sorted out with whoever owns the current source publishing mechanism
16:48:16 <imcleod> jzb: This is w.r.t. the "rebuild"?  So yes, that's actually one issue we had talked about.  There is a pipeline for RPM sources but not for other rel-eng material.
16:48:56 <imcleod> I can take that action.  "Ian to try to establish release scheme for image kickstarts and Dockerfiles"
16:49:06 <jzb> imcleod: awesome, thanks
16:49:22 <jzb> #action imcleod try to establish release scheme for image kickstarts and Dockerfiles.
16:49:59 <jzb> any other topics?
16:50:06 <kbsingh> yes, i have one
16:50:31 <jzb> kbsingh: OK
16:50:46 <kbsingh> we should ahve 7 1503 baked and out in a few days, the CR/ repos already have content.
16:51:09 <kbsingh> the April builds for the rolling side of things would be a good place to try and target a new / fresh crop of images.
16:51:32 <jzb> kbsingh: and those cut when?
16:51:48 <kbsingh> given the personal nature of how we work, there is no real cut off - but it would be good if we can (a) do a dry run and scope out what all we want to push by the middle of april and (b) get some level of testing in place before then.
16:52:09 <kbsingh> the actual 'release?' builds will run against the 28th April tree, so on the 29th.
16:52:16 * jbrooks has been building custom trees from the cr repo
16:53:13 <jbrooks> It seems that we should be able to have everything squared away for a stable April release?
16:53:30 <jbrooks> What about the lvm-backing for the qcow images?
16:53:37 <jbrooks> What's blocking that?
16:54:05 <kbsingh> lets find out around the middle of April :)
16:54:37 <jzb> kbsingh: o.O
16:54:42 <kbsingh> if we can scope things up and run a set of builds for the 16th Apr meeting -> rock. gives us 2 weeks to resolve issues.
16:55:45 <jzb> OK
16:55:58 <jzb> Anything else today? We're close to 1hr
16:56:30 <kbsingh> I'm good.
16:56:43 <jzb> kbsingh: btw, I don't see any tea & biscuits
16:56:55 <kbsingh> you will, this time next week :)
16:57:01 <jzb> speaking of
16:57:12 <jbrooks> tea & biscuits... Of The Mind
16:57:18 <jzb> Several of us will be in in-person meetings next week, so I'm going to suggest we skip next week's meeting
16:57:29 <jzb> will send a note to that effect to the list
16:57:32 <jzb> thanks all!
16:57:36 <jzb> #endmeeting