14:02:32 <jzb> #startmeeting
14:02:32 <zodbot> Meeting started Thu May  8 14:02:32 2014 UTC.  The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:34 <roshi> it doesn't go unnoticed red_trela
14:02:38 <jzb> roll call, pls
14:02:40 <jzb> .fasinfo jzb
14:02:41 <zodbot> jzb: User: jzb, Name: Joe Brockmeier, email: jzb@zonker.net, Creation: 2010-04-20, IRC Nick: jzb, Timezone: America/Chicago, Locale: en, GPG key ID: A0207CD4, Status: active
14:02:44 <zodbot> jzb: Approved Groups: marketing cla_done cla_fpca cla_fedora
14:02:50 <mattdm> .hellomynameis mattdm
14:02:51 <zodbot> mattdm: mattdm 'Matthew Miller' <mattdm@mattdm.org>
14:02:57 <roshi> .fasinfo roshi
14:02:58 <zodbot> roshi: User: roshi, Name: Mike Ruckman, email: mruckman@redhat.com, Creation: 2013-08-24, IRC Nick: roshi, Timezone: US/Mountain, Locale: en, GPG key ID: , Status: active
14:03:01 <zodbot> roshi: Unapproved Groups: magazine marketing
14:03:04 <zodbot> roshi: Approved Groups: +qa fedorabugs qa-admin cla_done cla_fpca
14:03:05 * red_trela 
14:04:42 <geppetto> .hellomynameis geppetto
14:04:43 <zodbot> geppetto: Sorry, but you don't exist
14:04:50 <mattdm> geppetto ouch
14:04:51 <mhayden> .hellomynameis mhayden
14:04:52 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net>
14:04:57 <roshi> yeah, ouch
14:05:02 <geppetto> .fas james
14:05:03 <zodbot> geppetto: jkirklan 'James Kirkland' <jkirklan@redhat.com> - jpuellma '' <james.puellmann@gmail.com> - jwykeham 'James Wykeham-Martin' <jwykeham@gmail.com> - devteamrox 'Tracy James Williard' <deathjr454@yahoo.com> - ephesus 'James Rubingh' <ephesus@gmail.com> - k44k 'James P' <carlcold.cc@gmail.com> - jpaisley '' <jamescampaisley@mac.com> - jrsmith 'James R. Smith' <james.smith@la.gov> - jcmartin 'James C Martin' (50 more messages)
14:05:21 <geppetto> .fas james@
14:05:22 <zodbot> geppetto: rochja 'Roy James' <roy.james@easy.com> - jamestech 'James Collins' <james@rgveaglegroup.us> - jvasser 'James L. Vasser' <james@jamesvasser.com> - dragonnet 'James Austin' <james@dragon-net.co.uk> - hm2k 'James Wade' <james@hm2k.org> - insydney 'James Litten' <james@insydney.com.au> - alx999 'Alex James' <alx.james@gmail.com> - purpleidea '' <james@shubin.ca> - tebidh 'James Brandon' <james@nnjb.org> - (6 more messages)
14:05:30 <geppetto> le sigh
14:06:15 <jzb> ok, let's get going
14:06:26 <roshi> proposed #agreed: geppetto exists and we count them here
14:06:34 <geppetto> +1:)
14:06:44 <jzb> roshi: +1
14:06:57 <jzb> let's start with ticket 51?
14:07:04 <jzb> #topic start communication/collaboration on cloud image updates
14:07:12 <jzb> #info https://fedorahosted.org/cloud/ticket/51
14:08:01 * jzb looks at last week's minutes
14:08:11 <mattdm> yeah we had some activity here
14:08:11 <jzb> looks like we were agreed on actions for this one.
14:08:31 <mattdm> I think it was "ooh, make jzb do it!"
14:08:33 <mattdm> right? :)
14:08:39 <roshi> that's what I remember
14:08:53 <jzb> some of it, yes
14:08:54 <red_trela> if it wasn't, let's make it so ;)
14:09:03 <roshi> and after searching the whole of the internet - I can find nothing to the contrary
14:09:07 <mattdm> in seriousness, yes, that was not the whole thing.
14:09:21 <jzb> mattdm: any traction on GCE?
14:09:43 <mattdm> jzb touche! That is my action item that I just remembered about yesterday afternoon
14:10:05 <mattdm> i was going to mention that later :)
14:10:42 <jzb> mattdm: so still in progress?
14:10:57 <mattdm> jzb yes, but I need to send some e-mails
14:10:59 <jzb> mattdm: don't feel bad - I have not gotten very far on the update policy
14:11:13 <walters> hi all, sorry for being late
14:11:20 <jzb> walters: howdy
14:11:34 <mattdm> yeah, so, I think the status on both of those is "in progress, kinda slow, but not blocked"
14:11:40 <mattdm> so let's move on to the next thing?
14:11:44 <jzb> sounds good
14:12:08 <jzb> since we have walters, I think we needed to discuss docker image and yum/dnf/rpm-ostree?
14:12:21 <mattdm> yeah. that sounds good.
14:12:30 <jzb> #topic yum/dnf rpm-ostree
14:12:31 <mattdm> walters -- I meant to reply to your message about bootloaders on the list
14:12:46 <mattdm> we can probably do that there and not take up meeting time?
14:12:54 <walters> yeah, sounds good
14:13:51 <jzb> walters: if I'm not mistaken, there may be some confusion about what rpm-ostree will require to allow installing packages when you get to that stage?
14:14:28 <mattdm> particularly: do we need python to bootstrap installing other stuff
14:14:35 <mattdm> or does it just need the c library parts?
14:14:49 <walters> jzb, http://lists.rpm.org/pipermail/rpm-maint/2014-April/003682.html
14:15:12 <walters> mattdm, a key question here is what people can do in min-metadata-service userdata
14:15:26 <walters> we'll support #!/bin/sh obviously
14:15:50 <jzb> #info http://lists.rpm.org/pipermail/rpm-maint/2014-April/003682.html
14:16:28 * mattdm skims linked message
14:16:49 <walters> so...my feeling is to keep python(2) for now, but say that the host may become smaller in the future
14:16:59 <geppetto> walters: Did you speak to anyone on IRC about that?
14:17:06 <walters> geppetto, nope
14:17:47 <mattdm> walters this is because python might be needed by scripts in additional layers?
14:17:53 <geppetto> walters: So … at one point you'd talked about doing the install as a complete new tree install, and then linking in the parts of the tree that are different from the current tree … which solves all this whitelisting problem
14:17:57 <mattdm> or because it's handy to have for init scripts?
14:18:16 <mattdm> um, not "init". rpm.
14:18:24 <geppetto> walters: Is that a future plan, or is the modify the current tree thing have advantages you don't want to lose?
14:18:29 <mattdm> gah. no. cloud-init. i mean. seriously, brain.
14:18:57 <walters> mattdm, mmm...it's more that it seems people use python in userdata a fair bit
14:19:10 <walters> with cloud-init you can expect it of course
14:19:26 <red_trela> I think we were aware python might be handy for some use cases, when we decided against it in the atomic image.
14:19:39 <walters> say we only support "#!/bin/sh" - but that just begs the question of what utilities you can call.  Is e.g. curl guaranteed?
14:19:41 <red_trela> the question is, are there plans to make it a hard requirement in rpm-ostree?
14:19:51 <walters> make python a hard req?  nope definitely not
14:19:57 <samkottler> just install python if you need it?
14:20:02 <walters> ok sorry if you guys had decided against it then i'm fine with that
14:20:07 <samkottler> and then the shebang can point anywhere
14:20:13 <mattdm> walters We had decided to try without it.
14:20:14 <geppetto> Right … and if we have libhawkey and everything below it (like rpm/sqlite/db4/etc.) and we have python … not shipping dnf/yum seems pretty insane.
14:20:28 <mattdm> +1 geppetto
14:20:41 <geppetto> but I'm much less sure people want python in the Atomic image.
14:20:49 * samkottler is really against not shipping a package manager which isn't ostree
14:21:09 <mattdm> samkottler too many nots can't read
14:21:15 <jzb> samkottler: can you rephrase?
14:21:17 <walters> geppetto, re your earlier messages on layering, it's a complex topic, let's take it to email or something
14:21:17 <geppetto> samkottler: you sure you have the right number of negatives there?
14:21:21 <jzb> I hit a parsing error
14:21:25 <samkottler> sorry, that was a terrible sentence: I believe we need to ship a package manager other than ostree
14:21:37 <jzb> samkottler: thanks
14:21:42 <mattdm> samkottler even in the atomic image?
14:21:53 <geppetto> walters: ok
14:22:04 <mattdm> plan is to keep traditional yum in 'cloud base' iamge
14:22:04 <samkottler> mattdm: TBH yeah
14:22:14 <walters> geppetto, re hawkey/librepo cloud has a regular yum-based image right?  this is trying to be edgy with the special docker host
14:22:38 <walters> though this does raise the point that docker isn't actually cloud specific and my anaconda work will allow baremetal installs
14:22:49 <samkottler> ostree is so prescriptive in it's approach that having it as the sole option might be a turn-off to some people
14:23:09 <mattdm> yeah. for this, I'd like to be experiment with being extra edgy, and point the other people to our other more conservative option
14:23:10 <walters> samkottler, i agree, we need a regular image too
14:23:23 <mattdm> double the work, but best of both worlds :)
14:23:41 * geppetto can't wait for walters to get the BZs about people who installed the Atomic image and then yum install'd all day on it ;)
14:23:49 <samkottler> geppetto: heh, yep.
14:24:11 <walters> geppetto, related to that can you have yum check say for /usr being a ro bind mount and give a useful error?
14:24:14 <samkottler> I'm fine with two images
14:24:19 <jzb> samkottler: really, the Docker image is mainly all about running Docker containers, though - how much modification do we need to do with that host?
14:24:39 <geppetto> walters: yeh, if there's a decent API for it (please don't tell me to parse /proc/mounts)
14:25:03 <mattdm> I think we should draw the initial atomic image very small, and also go out of our way to list stuff that is pulled in but not necessarily meant to be as 'not promised'
14:25:16 <walters> mattdm, that sounds good
14:25:28 <roshi> how many images are we going to end up with?
14:25:39 <jwb> i have a question on this when you get a sec
14:25:45 <mattdm> that is, if something pulls in curl, we should list whether we mean it to be part of the "api"
14:25:55 <samkottler> ricky: seems like 5-7 right now
14:26:04 <samkottler> sorry ricky, roshi ^^
14:26:14 <mattdm> roshi right now, three. generic cloud base, fedora atomic (docker), and big data
14:26:29 <mattdm> four if you count i386 generic separately (the other two will be 64-bit only)
14:26:39 * jzb grumbles that little data gets no respect
14:26:46 <walters> geppetto, os.access('/usr', os.W_OK) ?
14:26:49 <mattdm> little data goes in the docker images :)
14:27:10 <roshi> ok
14:27:17 <walters> i think my feeling here is to support curl forever
14:27:28 <red_trela> five if someone feels seriously edgy and wants to try go arm with atomic ;)
14:27:32 <geppetto> walters: Sure … obviously need more tea :)
14:27:43 <mattdm> I kind of hope that the world goes in a way such that explosion of options happens at the container layer and we can keep with a handful of these
14:27:45 <walters> red_trela, docker doesn't support arm
14:28:03 <red_trela> walters: that's where the 'seriously edgy' is coming from :)
14:28:33 <red_trela> walters: it's not the only part that doesn't officially support arm, yet :)
14:28:40 <walters> one topic on both atomic and docker - i have a feeling the rel-eng work here is going to be substantial
14:28:47 <mattdm> walters yeah, curl is probably One Of Those Things. but we should make a list.
14:28:57 <mattdm> anyone want to volunteer to work on that?
14:28:58 <walters> we have to figure out how more people can pitch in
14:29:01 <mattdm> doesn't need to be done now :)
14:29:09 <mattdm> calling scollier!
14:29:25 <scollier> hey mattdm
14:29:40 <mattdm> I asked scott if he could help pitch in :)
14:29:51 <walters> basically the way i'd do it is scour existing cloud-init user data for what they do
14:30:05 <walters> some are going to be blocked on package layering
14:30:16 <jzb> mattdm: do you want to create a ticket for All the Things?
14:30:18 <walters> but others are just calling /sbin/adduser and such
14:30:24 <mattdm> jzb yeah, I'll file the ticket now
14:30:52 <jzb> #action mattdm create All the Things ticket (components needed for image)
14:32:59 <walters> on the ostree side, i have approval for most anaconda patches, and as you guys saw I was looking at the cloud kickstart and looking at plans for EC2/OpenStack images
14:33:40 <mattdm> #link https://fedorahosted.org/cloud/ticket/54
14:33:43 <walters> i have started breaking up rpm-ostree in git master
14:33:52 <walters> the "treecompose" step lives in the core
14:34:01 <walters> everything else is now in https://github.com/cgwalters/rpm-ostree-autocompose
14:34:15 <walters> (everything else being the automatic qcow2 generation, smoketesting, etc.)
14:34:25 <walters> with the goal that treecompose becomes a Koji plugin
14:35:52 <mattdm> #link https://fedorahosted.org/cloud/ticket/55
14:36:11 <jzb> OK, anything more on this topic?
14:36:16 <jwb> i have a question
14:36:29 <jwb> i think it's related anyway
14:36:30 <mattdm> #info I made two tickets, one for the atomic list and one for generic
14:37:03 <jzb> jwb: shoot
14:37:31 * walters only now notices the different middle character in jzb and jwb
14:37:47 <jwb> yesterday walters pasted an irc conversation about atomic in the cloud.  the very bottom of it talked about doing things like removing kernel drivers in the image
14:38:02 <jwb> which... is what the kernel packaging work i've been doign is for
14:38:13 <jwb> so is that now unnecessary, or?
14:38:19 <jwb> slightly confused.
14:38:30 <walters> jwb, yep i'm aware, looking forward to it  (for a while i was stripping e.g. the radeon drivers and firmware manually but if you have packages split it's clearly way better)
14:38:54 <mattdm> e.g. walters' approach is gross and we want him to quit that. :)
14:39:02 <walters> yes =)
14:39:12 <jwb> ok.  well, packages are split.  the contents between kernel-core and kernel-modules can be altered, but radeon is still in there right now
14:39:29 <walters> the ability to post-process rpm content with ostree is handy, but for this modularizing the RPMs is clearly better
14:40:00 <jwb> ok.  just wanted to make sure what's been done in the kernel package was actually going to be used, because if not i was going to revert it
14:40:06 <dgilmore> walters: I wont enable a ostree plugin.
14:40:16 <walters> jwb, i don't think anyone has tried it for cloud yet
14:40:20 <walters> dgilmore, ?  why not?
14:40:27 <dgilmore> walters: you should write a fedmsg listener that takes action on builds
14:40:47 <jwb> red_trela did most of the testing... so someone did?
14:40:57 <dgilmore> walters: because the build would not complete until the plugin completed all its taskks
14:41:00 <dgilmore> tasks
14:41:14 <red_trela> jwb: even if it wasn't used in the atomic image, it still will be used in the other (two) cloud images which don't use ostree
14:41:42 <red_trela> I did some simple, quick testing in a few environments but further testing will surely be necessary
14:41:44 <mattdm> +1 red_trela. And that's going to be with us for a good long time.
14:41:45 <jwb> ok.  thanks for clearing it up
14:41:45 <walters> dgilmore, ok let's take the details of this to another thread, i'm still cleaning up the rpm-ostree side in preparation for more integration somehow
14:43:27 <dgilmore> walters: sure
14:43:33 <mattdm> okay, so, any more things we need to take action on here? i think the basic question is clearned up.
14:43:44 <jzb> mattdm: +1
14:44:06 <dgilmore> mattdm: we do not have a good way to ship trees
14:44:17 <red_trela> so no changes to the current atomic image plans, right?
14:44:43 <red_trela> i.e. still no python/yum/dnf? :)
14:45:11 <jzb> red_trela: thanks, yeah - let's clarify the decision
14:45:17 <mattdm> dgilmore Yes, highly aware that that's a blocker here.
14:45:22 <jzb> anyone disagree with the above?
14:45:35 <walters> dgilmore, can you write up your thoughts on this somewhere?  We have an old fedora-infra ticket here https://fedorahosted.org/fedora-infrastructure/ticket/4200
14:45:41 <dgilmore> mattdm: we need to engage mirrors and work out how we can ship things
14:46:07 <dgilmore> walters: infra is the wrong place to bring up this type of discussion
14:46:07 <walters> also need to more formally decide what trees are shipped
14:46:10 <mattdm> and unless I misunderstood this is one of the things scollier said he was interested in helping with
14:46:15 * mattdm shoves scott further under the bus
14:46:41 <mattdm> dgilmore should the ticket be moved to releng?
14:46:45 <mattdm> or fesco?
14:46:47 <mattdm> or?
14:47:18 <roshi> where's a good place to get a rundown on this whole topic - because I barely understand what we're talking about
14:47:22 <roshi> ?
14:47:41 <dgilmore> mattdm: well, I thought we had agreement that we would not try to ship any trees.
14:47:42 <walters> roshi, http://www.projectatomic.io/
14:47:47 <mattdm> roshi: probably http://rpm-ostree.cloud.fedoraproject.org/
14:47:50 <dgilmore> we need to talk with mirrors
14:48:01 <roshi> thanks
14:48:05 <dgilmore> we need to sort out how to make and ship the trees
14:48:11 <walters> roshi, https://fedorahosted.org/cloud/ticket/46
14:48:12 <dgilmore> we need to sort out qa for them
14:48:22 <mattdm> dgilmore okay, but where is the best place to have that top level conversation? cloud list? releng list?
14:48:25 <dgilmore> mattdm: way too many unanswered questions
14:48:34 <mattdm> yes, let's get the questions answered
14:48:49 <dgilmore> mattdm: i think it needs to happen in multiple places
14:48:56 <mattdm> I don't think we have all the answers right here though -- or even the question.
14:48:57 <dgilmore> mattdm: releng list seems like a good start
14:49:04 <dgilmore> but QA needs involved also
14:49:24 <jzb> mattdm: 42? 6x9?
14:49:26 <mattdm> dgilmore Okay. I will make a tracking ticket for this in the cloud system
14:49:42 <dgilmore> mattdm: there is a few different issues
14:49:42 <walters> my employer now has me fulltime on ostree and projectatomic stuff, so i'll be responsive to any concerns
14:50:10 <dgilmore> mattdm: the different issues invole different groups of people
14:50:13 <mattdm> #action mattdm to make high-level ticket covering issues with shipping ostree trees... this will fork into qa and releng and mirror conversations
14:51:14 <dgilmore> mattdm: but from my discussions with walters I though e had agreement that we would not try to ship ostree trees anytime soon
14:51:19 <scollier> mattdm, back.  i'd like to help on that ticket
14:51:30 <mattdm> scollier awesome thanks.
14:51:31 <dgilmore> so i am a bit unhappy that we are now trying to do it
14:51:45 <walters> dgilmore, well rawhide, but yes.  Then projectatomic.io happened
14:52:03 <dgilmore> walters: doesnt matter
14:52:05 <walters> and it went from being my side project to my job
14:52:09 <mattdm> dgilmore I think, overall, we really want to do this, and need to figure out how.
14:52:23 <mattdm> That includes finding out what new resources might be needed if we need them.
14:52:46 <dgilmore> mattdm: im not sure we can. but im happy to try and work it out. just expressing my dissatisfaction at it being slipped in the backend
14:53:37 <dgilmore> mattdm: by not sure we can i mean using mirrors. we may need to work out a new delivery method
14:54:00 <walters> i would say if it slips it's not the end of the world - we're going to have a regular cloud image regardless.  But we have dedicated resources to try atomic
14:55:56 <mattdm> #link https://fedorahosted.org/cloud/ticket/56
14:56:11 <jzb> mattdm: thanks
14:56:24 <mattdm> #info tracking ticket for conversations around shipping ostree... trees.
14:56:31 <jzb> OK, we're near the end of our time and seem to be out of new tickets
14:56:44 <jzb> any other items or topics we need to discuss today?
14:56:45 <mattdm> #halp that ticket -- needs help. please add yourself to cc if interested.
14:56:57 <mattdm> jzb -- yes, we should talk about wg membership
14:57:13 <red_trela> agreed
14:57:16 <mattdm> I think that everyone in the wg expressed interest in continuing
14:57:26 <jzb> mattdm: I don't think Frankie ever spoke up
14:57:37 <mattdm> jzb hmmm. okay.
14:57:38 <jzb> oh, my bad
14:57:41 <jzb> yes, he did
14:58:03 <mattdm> mrunge mentioned that he would like to stay involved but is busy and could step down to make room for someone else
14:58:43 <mattdm> I was talking to scollier (as mentioned) and he expressed interest, particularly around atomic and docker
14:59:26 <scollier> mattdm, yes, if i can be of assistance, I'm happy to.  Esp. around fedora-dockerfiles and Docker images moving forward.
14:59:31 <jzb> mattdm: should we put out a "call" for any interested applicants?
14:59:41 <jzb> (not to knock scollier)
15:00:12 <jeid64> I would be interested, but I don't think I have enough experience yet.
15:00:17 <mattdm> Assuming scott is still interested, maybe I'll talk to matthias about it?
15:00:31 <jzb> we had someone else speak up on the mailing list
15:00:35 <mattdm> I'm glad to see more interest in being involved than voting members
15:00:43 <mattdm> this is not a problem I'd really worried about :)
15:00:54 * roshi is content where he is unless you guys deem official "membership to the WG" as something I need
15:01:37 <jzb> so, a proposal: We mention we have an open seat on the list and give folks 72 hours to throw their hats in the ring, if they haven't already
15:01:48 <mattdm> we haven't really had any contentious votes, so I'm kind of open to the idea of just not worrying about it and say that everyoen can play?
15:02:42 <mattdm> I can be +1 to jzb's proposal, though.
15:02:58 <jzb> I tend to be a stickler for process
15:03:01 <jzb> sorry :-)
15:03:14 <mattdm> jzb it's good to have some of that about to keep us hippies in line
15:03:45 <mattdm> we can do both, though, really -- say that we have an opening, but also stress that everyone is awesome
15:03:46 <red_trela> I think having clear rules and sticking to them is important. We can change rules if desired, though.
15:03:48 <roshi> lol
15:04:07 <mattdm> okay, so, process! anyone object to jzb's proposal?
15:04:16 <jeid64> +1 to jzb's proposal.
15:04:20 <red_trela> I'd also appreciate if we keep a certain RH/community balance in the wg
15:04:46 <red_trela> +1 to jzb
15:04:51 <mattdm> red_trela mrunge is @redhat, if that matters
15:05:01 <red_trela> mattdm: I know
15:05:24 <mattdm> He works on RDO, and was most interested in cattle-like images on hardware, if I remember right
15:05:26 <geppetto> +1, seems fine
15:05:33 <red_trela> I'd also say we ask other rather inactive wg members to step down if we have really good/active candidates
15:05:43 <red_trela> mattdm: yes
15:05:44 <mattdm> which we're not ready for, so, everything kind of falls out from that
15:05:49 <mattdm> red_trela +1 to that
15:06:11 <jzb> red_trela: now, or later ?
15:06:30 <red_trela> jzb: well, as soon as we have more candidated we'd like in the wg than open seats ;)
15:06:52 <red_trela> (not sure if the number of seats is fixed, though)
15:07:07 <jzb> ok, so we have 3 +1's and no -1s
15:07:50 * jzb realizes he forgot to chair folks at the beginning of the meeting. Apologies.
15:08:02 <jzb> rbergeron, number80 ^^ ?
15:08:07 <jzb> samkottler: ^^ ?
15:08:19 <red_trela> I tend to think too many chairs spoil the log ;)
15:08:20 <mattdm> red_trela number of seats is fixed by the governance, but we gave ourselves leave to change that :)
15:09:04 <samkottler> jzb: +1
15:09:30 <red_trela> too many seats also tend to spoil the quorum, but I figure we never defined one anyway ;)
15:09:53 <jzb> OK, we're going with lazy consensus so we're good
15:10:08 <jzb> I'll shoot an email to the list asking for folks to raise their hand.
15:10:20 <jzb> we can discuss then how to vote
15:10:45 <jzb> #action jzb Solicit folks who want to volunteer for the WG
15:10:55 <jzb> ok, any objections to adjourning?
15:11:11 <red_trela> +1 to adjourning
15:11:16 <jeid64> Oh
15:11:20 <jeid64> I was going to bring up one more thing.
15:11:31 <jeid64> number80 and I were talking about getting work started on the big data image
15:12:09 <jzb> jeid64: OK
15:12:11 <jeid64> We were interested in mailing the big data SIG list and asking for their advice on packages and other configs that should be in the images, and see if there's interest on their side for testing and working on it.
15:12:25 <mattdm> that sounds good
15:12:57 <red_trela> make it so
15:13:09 <jeid64> And it should be a kickstart based image off the cloud-base kickstart, right? I've been seeing a lot of things about docker and projectatomic, but I thought we were going for actual images for the bigdata image.
15:13:33 <red_trela> correct
15:13:54 <jeid64> Okay, good to go then. +1 to adjourning.
15:13:58 <red_trela> and x86_64 only
15:14:22 <jzb> going once....
15:14:42 <jzb> twice
15:14:47 <jzb> OK
15:14:50 <jzb> #endmeeting