14:02:21 <jzb> #startmeeting
14:02:21 <zodbot_> Meeting started Thu May  1 14:02:21 2014 UTC.  The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:21 <zodbot_> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:42 <jzb> chair mattdm red_trela rbergeron number80 samkottler geppetto
14:02:47 <jzb> er
14:02:54 <jzb> #chair mattdm red_trela rbergeron number80 samkottler geppetto
14:02:54 <zodbot_> Current chairs: geppetto jzb mattdm number80 rbergeron red_trela samkottler
14:03:05 <jzb> so early, such meeting, wow
14:03:11 <jzb> roll call?
14:03:14 <jzb> .fasinfo jzb
14:04:19 * red_trela 
14:05:04 <red_trela> well, the others sure have a short attention span
14:05:20 <jsmith> .fasinfo jsmith
14:05:47 * jzb wonders why that's not working
14:05:48 * mattdm is back
14:05:50 <mattdm> sorry
14:06:10 <jsmith> Looks like zodbot is asleep on the job :-p
14:06:21 <jzb> well, let's get started...
14:06:21 <mattdm> .hellomynameis mattdm
14:08:31 <jzb> #topic Crucial basic Docket Host Image decisions
14:08:31 <jzb> #info https://fedorahosted.org/cloud/ticket/47
14:08:32 <jzb> this is ticket 47, filed by red_trela
14:08:32 <jzb> red_trela: you want to start the discussion?
14:08:33 <mattdm> pasting from ticket:
14:08:33 <mattdm> Whether to use (rpm-)ostree (aka Fedora Atomic Initiative)
14:08:33 <mattdm> Whether to remove yum/dnf (if going with ostree)
14:08:33 <mattdm> Whether to replace cloud-init by coreos' cloud-init or min-metadata-service
14:08:33 <mattdm> Whether to kick out python (if we decided against yum/dnf and cloud-init)
14:10:47 <number80> hi
14:10:47 <mattdm> oh hai zodbot_
14:10:47 <red_trela> sure
14:10:47 <number80> i thought we were talking about dockah
14:10:47 <red_trela> so there's those 4 rather crucial decisions that we should make regarding the Docker Host Image (which is not the Atomic Image or whatever).
14:10:47 * mattdm nods
14:10:48 * rbergeron migrates to awakeishness
14:10:48 <jzb> red_trela: do we want a non-Atomic docker host image?
14:10:48 <mattdm> jzb I think that we want to make sure that the generic image can be used that way if desired
14:10:48 <red_trela> uhm, do we? I thought we made the docker host image the atomic image last week - or did we just add an image?
14:11:08 <number80> i'm confused
14:11:13 <mattdm> and as red_trela says, _the" docker host image should be Fedora Atomic.
14:11:16 <geppetto> red_trela: yeh, we all voted for 46 I thought
14:11:36 <mattdm> so I think the first point is confirmed. the rest are followups from there really
14:14:17 <red_trela> mattdm: exactly
14:14:18 <number80> ok
14:14:19 <geppetto> I think #2 and #4 pretty much follow on … there's little point in keeping yum/dnf if the host is managed by ostree
14:14:19 <red_trela> unless someone thinks we should vote on whether or not doing both (atomic and non-atomic) docker host images - current status is atomic only
14:14:19 <number80> +1 about removing python and its dependencies
14:14:19 <geppetto> #3 I'm not as sure about … someone want to bring up the pros. cons. of cloud-init with ostree?
14:14:20 <number80> but i don't think it's feasible before f22
14:14:20 <jzb> geppetto: eventually rpm-ostree is supposed to allow installing packages
14:14:21 <mattdm> let's do these in order?
14:14:21 <jzb> not sure if that will be in the F21 timeframe or not, but we should check in with Colin about that.
14:14:21 <mattdm> #1 I think we're all agreed on. So moving on to #2...
14:14:21 <geppetto> jzb: yeh, but it's doing so via. ostree which links to libhawkey
14:14:21 <geppetto> jzb: 3 package managers in F22 ftw :)
14:14:21 <mattdm> And I agree that yum/dnf don't make sense in ostree. in fact they are likely to break stuff.
14:14:21 <mattdm> unless geppetto says otherwise :)
14:14:26 <geppetto> no, I agree
14:14:44 <mattdm> anyone _not_ agree?
14:15:11 <mattdm> the sound of crickets is assent!
14:15:36 <red_trela> so, do we vote on that or is no opposition good enough to go with it?
14:15:47 <mattdm> #agreed fedora atomic docker-specific image will not include yum/dnf
14:16:05 <mattdm> red_trela I'm good with no opposition -- that's basically our governance plan
14:16:48 <mattdm> so cloud init is more controversial.
14:17:02 <red_trela> so the next point would once again be cloud-init. I figure we already had this topic a short while ago and I think someone wanted to bring it to the list?
14:17:09 <red_trela> (also once again)
14:17:17 <mattdm> I know samkottler was just very recently saying he was interested in trying to make it work
14:17:38 <red_trela> make min-metadata-service work, that is, right?
14:17:38 <mattdm> From the previous discussion, sdake isn't concerned about heat requirements for the docker-specific image
14:17:53 <mattdm> red_trela yes
14:18:20 <mattdm> proposal: try it for alpha, fall back to cloud-init for beta if it doesn't work out
14:18:33 <jzb> +1
14:18:37 <mattdm> and keep cloud-init in the generic image
14:19:01 <jsmith> +1 from me
14:19:06 <mattdm> the downside is... two things. counterbalanced by one really eing a subset of the other
14:19:36 <number80> i think i alreadt requested an account on fedora cloud for developping min-metadata-service but having it in f21 is very optimistic
14:19:57 <red_trela> I'm still not very convinced min-metadata-service is the best alternative, but I'm +1 to try any alternative ;)
14:20:16 <number80> -1
14:20:19 <mattdm> number80 what are the concerns?
14:20:42 <number80> making it work with aws, openstavk, requires a lot of testing
14:21:13 <mattdm> another argument for it in my mind is that many of the things one could do with cloud-init are things one _shouldn't_ do with atomic
14:21:30 <mattdm> (like, install and configure packages)
14:21:31 * roshi walks in late
14:22:15 <mattdm> number80 we've got a little while before we _really_ have to decide for alpha ... do you want to defer the decision to closer to then to see how it is looking?
14:22:42 <number80> sure, we have many things running
14:22:54 <mattdm> okay, so:
14:22:57 <number80> (sorry for th slow typing)
14:23:25 <mattdm> proposal: defer min-metadata-service til closer to alpha, encourage people interested in it to continue development
14:23:37 <rbergeron> number80: are those concerns for just the docker host image? or is that "if we tried to make it work for the generic image"
14:24:22 <red_trela> the thing really is, the last point (removing python) really depends on this - and doing that last-minute might not work well
14:24:57 <red_trela> putting python/cloud-init back in last-minute on the other hand, should be much less troublesome
14:25:19 <mattdm> good point red_trela
14:25:23 <rbergeron> mattdm: defer it .. but not for generic image, that's comfirmed to stay w/cloud-init as we kust discussed. yes?
14:25:37 <red_trela> (just hoping I'm not summoning trouble here)
14:25:48 <mattdm> rbergeron yes.
14:26:22 <number80> rbergeron: both
14:26:26 <mattdm> and _especially_ since we are (resigned to?) keeping cloud-init in the generic image, we'll know that switching back to that should work.
14:26:28 <rbergeron> okay. just making sure - we just listed out a long list of options ;)
14:26:46 <number80> i'd like to see more advancements before taking a decision
14:27:18 <number80> i'll change my vote +0 ;)
14:27:53 <rbergeron> (also, i need sdake to bring me lunch today and cannot jeopardizr that. no, no, just kidding)
14:28:26 <red_trela> so, let's go with mattdm's proposal?
14:28:45 <mattdm> red_trela the defer one or the first one?
14:28:57 <red_trela> the try it for alpha one
14:29:09 <mattdm> I'm still +1 :)
14:29:36 <red_trela> everyone is +1 or +0, so next :)