16:06:00 <jzb> #startmeeting CentOS Atomic SIG meeting
16:06:00 <centbot> Meeting started Thu Mar 12 16:06:00 2015 UTC.  The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:00 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:06:46 <jzb> #chair walters jbrooks imcleod kbsingh Evolution
16:06:46 <centbot> Current chairs: Evolution imcleod jbrooks jzb kbsingh walters
16:07:29 <jzb> OK, let's look at last week's AIs
16:07:52 <jzb> kbsingh: you had the AI to move the vbox images to buildlogs, and change links to most recent
16:07:55 <jzb> I belive that's happened.
16:08:02 <jzb> so all good there.
16:08:47 <jzb> #topic upstream/downstream conversation
16:09:25 <jzb> last week we were discussing upstream/downstream and where / what CentOS SIG should be tracking
16:09:42 <jzb> kbsingh asked to push to this week, but I don't see him about.
16:09:50 <kbsingh> o/
16:09:55 <jzb> kbsingh: ah, there you are
16:10:08 <jzb> #info http://centos.org/minutes/2015/march/centos-devel.2015-03-05-16.07.log.html
16:10:12 <jzb> logs from last week
16:10:37 <kbsingh> there seems to be some level of expectation around the CentOS branding - if its called CentOS, people default to the mindset that its going to reflect similar ( or the same ) code and functional stuff as the RHEL Atomic
16:10:54 <kbsingh> given that were doing upstream work as well, how do we want to handle that
16:11:38 <jzb> kbsingh: So, question - does the "SIG" thing have any branding?
16:12:09 <jzb> kbsingh: one "solution" is to promote SIG branding for stuff like Atomic so it's clear that it's not stock CentOS
16:12:26 <jzb> kbsingh: the other is deciding whether CentOS will be doing a stock Atomic rebuild.
16:12:45 <kbsingh> agree on both
16:13:09 <jzb> kbsingh: we can position Atomic similarly to Xen for CentOS
16:13:32 <jzb> but we still need to take a decision on Atomic Host rebuild
16:13:39 <Evolution> I don't see a need.
16:13:47 <Evolution> from a core group perspective
16:13:48 <jzb> kbsingh: who decides that? I think that's maybe above the SIG.
16:13:52 <jbrooks> A need for what?
16:14:09 <jbrooks> To make a centos version of rhel atomic?
16:14:14 <Evolution> I don't see a need for the centos core to do a rebuild of rhel atomic.
16:14:24 <jbrooks> Ah, the core
16:14:27 <Evolution> if the sig wants to, that's fine and their decision.
16:15:10 <jzb> Evolution: you don't think there's demand for it?
16:15:18 <kbsingh> jzb: good question. in the end, it should boil down to the SIG to workout where they want to do - afaict, the SIG is focused on the upstream side of things.
16:15:41 <Evolution> jzb: I think having multiple builds would dilute the current demand, which is in its infancy.
16:15:51 <kbsingh> if the SIG opts out, then we can ping around into Core
16:16:10 <jbrooks> And the SIG we're talking about is this SIG, right? :)
16:16:16 <jzb> walters, imcleod ?
16:16:16 <kbsingh> jbrooks: indeed
16:16:19 <jbrooks> heh
16:16:21 <jbrooks> We
16:16:46 <Evolution> I'm not sure how to say this in a polite fashion, so please don't take this as hostile. it's not meant that way.
16:16:59 <walters> personally the most important thing to me is to get to the same architecture, not necessarily *exactly* the same code
16:17:05 <Evolution> just because rh drops source onto git.centos doesn't mean we're obligated to build it.
16:17:31 <kbsingh> Evolution: i dont think thats the question here though
16:17:44 <jbrooks> Of course, but this SIG was formed to build an atomic host. I agree that we don't have to be in lockstep w/ rhel atomic, though
16:17:45 <Evolution> kbsingh: for rebuilding rhel atomic?
16:17:46 <imcleod> Evolution: Heh.  That's reasonably polite.  And "having something that mirrors RHEL Atomic" is distinct from the question of who builds it.
16:18:25 <Evolution> imcleod: right. that's essentially the point I was going for. if the sig wants to, they're certainly welcome to
16:18:37 <kbsingh> Evolution: if there was an obligation, we'd already have the rpms in place
16:18:42 <imcleod> jzb: I agree with walters.  I'd prefer to see the primary focus of the SIG be something that is similar (and possibly even the quasi-official upstream for RHEL) without promising to be "as identical as possible" the way core does.
16:18:44 <jzb> Evolution: RHT I was looking at it more from a CentOS community demand.
16:18:52 <kbsingh> for where 'we' implies core sig, its just another sig for all purposes.
16:19:00 <Evolution> okay.
16:19:04 <imcleod> jzb, kbsingh: Is anyone "demanding" a near-mirror-image?
16:19:31 <Evolution> not that I've seen yet.
16:19:41 <kbsingh> imcleod: all feedback so far around centos atomic has been based on the assumption that its rhel atomic's clone build
16:19:42 <jzb> imcleod: so - I dunno about demand, I think we all saw the post about comparing CoreOS and Atomic last week?
16:19:43 <walters> second, I would like to figure out how CentOS could be a vehicle for "in development public" RHEL code
16:19:45 <kbsingh> so i'd say yes
16:20:03 <walters> atomic had to carry a newer systemd for a while, and that newer systemd was public in http://people.redhat.com/lnykryn/systemd/test/
16:20:12 <jzb> pretty much what KB said. People assume there's going to be a rebuild.
16:20:20 <kbsingh> there has been a chain of similar statements, including from cloud vendors who went to grab centos atomic to try it out :)
16:20:26 <imcleod> I think we should work to correct that assumption.
16:20:38 <jzb> so - I think demand is there.
16:21:44 <jzb> imcleod: it's been my experience that correcting assumptions like that is not trivial.
16:21:55 <kbsingh> can we agree that one thing on the table, not going away is : Atomic SIG is going to build and run ostree repos against code that is evolving, and be an upstream development platform for people wanting to consume and develop on the atomic platform ?
16:22:00 <jbrooks> rhel atomic is a sku of rhel, there will always be an assumption that there'll be a centos version of that -- but, as long as the basics are there, a host optimized for running containers, I don't think centos atomic must be the same
16:22:11 <jzb> kbsingh: yes
16:22:19 <kbsingh> i.e its not an either/or situation, the builds we do now - carry on happening. its just a case of if we want to add another, and if we do , how do we brand it
16:22:21 <jzb> kbsingh: I don't think there's any question of that.
16:22:29 <kbsingh> ok
16:23:13 <jzb> To make it easy - aside from me, any support for a rebuild of stock Atomic Host at this time?
16:23:24 <kbsingh> o/
16:23:35 <jzb> kbsingh: I'm not sure what that is :-)
16:23:51 <kbsingh> I'm in :)
16:23:58 <Evolution> I'm fine with it as well.
16:24:06 <kbsingh> subject to us finding a suiteable branding place
16:24:14 <imcleod> And building place....
16:24:24 <Evolution> kbsingh: does this circle back to your concept of 'upstream' repos again?
16:24:34 <kbsingh> imcleod: if its happening from the git sources, we'll just automte it into reimzul
16:25:35 <imcleod> kbsingh: K.  With tree construction pointing to what is essentially core?
16:25:44 <kbsingh> Evolution: good question. In this situation it feels the upstreams process, upside down - in that we are already the upstream ?
16:26:05 <jbrooks> We haven't been, though
16:26:18 <kbsingh> imcleod: w.r.t the rpms, and the ostree repo's backing it.. this is going to be a finite target i guess, so wont need user intervention ( haha! what doesnt )
16:27:41 <imcleod> Another element of a true rebuild, beyond just getting all the official RPM sources, would be the kickstarts and rpm-ostree JSON files.
16:28:14 <kbsingh> yup
16:28:16 <imcleod> I'm not sure if we have an official pipeline for getting those pushed out.
16:28:26 <kbsingh> so
16:28:36 <jzb> imcleod: we don't get those from RHEL for standard RHEL do we?
16:28:44 <jzb> (kickstarts)
16:28:50 <kbsingh> how about you ( imcleod ) and I take away a task for next week to come back with an apprasal of if this is even possible or not
16:28:54 <Evolution> jzb: nope
16:29:18 <imcleod> jzb: Other than perhaps the cloud images, there are no RHEL deliverables that require kickstarts.
16:29:25 <jbrooks> I'm for copying fedora's jsons and such, and feeding our own centos pkgs into that
16:29:48 <jbrooks> And using that as a starting point, to be modified from there, if we choose
16:29:55 <jzb> imcleod: ah.
16:29:57 <kbsingh> what happens when fedora jsons reference content not yet in the rhel atomic sources
16:30:02 <imcleod> jbrooks: I like that as a starting point as well, but that's not a rebuild.
16:30:21 <jbrooks> imcleod, Well, we can worry about having something stable and usable first?
16:30:21 <imcleod> kbsingh: +1
16:30:25 <imcleod> jzb: Could we categorize this as "Something to watch. Need more information?"
16:30:55 <kbsingh> I think we should go workout if this is going to be possible, and I think imcleod is the person to do the eval, with me providing tea and buiscuits
16:30:55 <jbrooks> If this approach of tracking Fedora works for ppl, great. If ppl want/need something closer to rhel atomic, we take that up
16:30:56 <imcleod> jbrooks: Yup.  I'm violently agreeing with you.
16:31:03 <jzb> imcleod: we could - I guess my concern is more "I tested this assuming it was a rebuild" noise.
16:31:21 <imcleod> jzb: We can't drive our SIG engineering decisions based on peoples incorrect assumptions.  :-)
16:31:27 <imcleod> "people's"
16:31:34 <jzb> kbsingh: since when are you providing tea and biscuits? I feel left out.
16:31:47 <jzb> imcleod: all engineering decisions are driven by marketing, ultimately. ;-)
16:31:58 <imcleod> jzb: I think we need some messaging on this point.  (And god help me for using "messaging" in a technical meeting.)
16:32:01 <jbrooks> We already know it's possible to build a usable workalike, so we can make that happen before or in parallel w/ pondering other possibilities
16:32:15 <jzb> imcleod: messaging is part of the SIG
16:32:22 <jbrooks> Or are ppl here saying that the straight rebuild route is whats preferable?
16:32:34 <imcleod> jbrooks: Not I.
16:32:47 <kbsingh> jzb: feature, not yet released :)
16:32:50 <jzb> jbrooks: not preferable. It's a question of do we deliver both...
16:33:10 <jzb> jbrooks: I think we're all committed to the idea of something that moves faster than RHEL.
16:33:19 <jzb> it's a question of if we also do the rebuild.
16:33:24 <jbrooks> OK, I vote for getting that out the door first
16:33:32 <jbrooks> A shipping thing
16:33:35 <jzb> jbrooks: which is that'?
16:33:53 <jbrooks> The one that doesn't require tea and biscuits :)
16:34:08 <jbrooks> Like, a finished version of what we've been working on for months
16:34:37 <kbsingh> http://wiki.centos.org/SpecialInterestGroup/Atomic/Download is that close ?
16:34:42 <jbrooks> RHEL Atomic is going to move faster than normal anyway, correct?
16:35:15 <jbrooks> kbsingh, That is great, I'm thinking of signing, of proper places to store our pkg sources, proper repos for the pkgs, etc
16:35:43 <jbrooks> Like, we need to mod our rpm-ostree pkg to allow the atomic cmd in there -- we do I send that PR?
16:35:57 <jbrooks> where do I send, I mean
16:36:19 <kbsingh> the deps into it need to be moved into release and signing as well
16:36:41 <kbsingh> so, lets keep making progress and keep iterating to get better
16:37:13 <kbsingh> jbrooks: maybe a doc that lists what a release state might look like ? that could be a potential todo list
16:37:25 <jbrooks> kbsingh, I'll take that item
16:37:44 <jbrooks> List of things that we need to have a stable release
16:38:03 <jbrooks> I'll use f21 atomic as a comparison
16:38:04 <jzb> #action jbrooks create stable release checklist
16:38:27 <jzb> (be careful when you volunteer, I'm quick with the action command.)
16:38:43 <Evolution> heh
16:38:45 <jbrooks> :)
16:38:47 <jzb> imcleod: were you willing to look into what actually is required for a rebuild?
16:38:54 <imcleod> jzb: Yup.
16:39:22 <jzb> #action imcleod investigate requirements for a rebuild of stock Atomic Host.
16:39:29 <jzb> #action kbsingh provide tea and biscuits.
16:39:39 * kbsingh gets the kettle on
16:39:44 <jbrooks> :)
16:40:00 <jzb> OK - I think we're at a logical stopping point right now for that discussion?
16:40:05 <kbsingh> yup
16:40:13 <jzb> #topic open floor
16:40:20 <jzb> anybody have new topics this week?
16:41:42 * jzb looks around
16:41:49 <jzb> OK, thanks all!
16:41:51 <jzb> #endmeeting.