17:00:23 <samkottler> #startmeeting Cloud WG weekly meeting
17:00:23 <zodbot> Meeting started Wed Nov 27 17:00:23 2013 UTC.  The chair is samkottler. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:37 <samkottler> #topic rollcall
17:00:42 * geppetto is here
17:00:44 <samkottler> \o
17:00:50 <rbergeron> heyooooo
17:00:59 <mrunge> heya!
17:00:59 <juergh> hi all
17:01:01 <samkottler> #chair geppetto mrunge number80 rbergeron mattdm frankieonuonga
17:01:01 <zodbot> Current chairs: frankieonuonga geppetto mattdm mrunge number80 rbergeron samkottler
17:01:27 <jzb> howdy
17:01:32 <samkottler> #chair jzb
17:01:32 <zodbot> Current chairs: frankieonuonga geppetto jzb mattdm mrunge number80 rbergeron samkottler
17:01:35 <mattdm> hi just a sec wrapping up Current Exciting Crisis
17:01:42 <gholms> Heh
17:03:49 * samkottler waits another minute for mattdm
17:03:58 <samkottler> we have a lot more people today than I was expecting :)
17:04:18 <mattdm> https://fedorahosted.org/cloud/ticket/4
17:04:27 <mattdm> just fyi :)
17:04:39 <rbergeron> samkottler: you haven't scared everyone off yet
17:04:47 <rbergeron> give it another minute or two :)
17:04:50 <samkottler> *yet*
17:05:03 <samkottler> #topic update on GCE legal and packaging things
17:05:26 <samkottler> so Fedora legal has said that people who wish to sign the google trusted tester document may do so individually
17:05:58 <samkottler> #info email shk@redhat.com if you want to get added to the trusted testers program or want to see the language associated with it
17:06:33 <number80> great
17:06:43 <samkottler> frankieonuonga, witlessb, and I started packaging the utlities we'll need
17:06:59 <samkottler> http://fedorapeople.org/cgit/skottler/public_git/google-compute-engine-packaging.git/
17:07:15 <samkottler> help would be much appreciated
17:07:18 <samkottler> commit for everyone!
17:08:02 <mattdm> samkottler awesome thanks
17:08:06 <gholms> Great!  How does that help us?
17:08:21 <mattdm> gholms fedora available in more public clouds
17:08:29 <samkottler> gholms: we'll need those tools to make fedora available in gce
17:08:35 <gholms> Wo's going to upload it?
17:08:42 <gholms> *Who's
17:08:54 <number80> samkottler: i could help
17:08:57 <gholms> Not rel-eng, I presume?
17:09:01 <mattdm> gholms eventually, release engineering. once we have it working.
17:09:13 <mattdm> rel-eng uploads ec2, and this is the same.
17:09:23 <gholms> I thought dgilmore wasn't going to do that.
17:09:50 <mattdm> gholms it could be someone working with him. dgilmore doesn't need more things piled on top of him, that's true.
17:09:50 <gholms> (the agreement thing, that is)
17:09:54 <number80> gholms: dgilmore needs moarr people to help him, so we need to get some people to join rel-eng
17:10:05 <gholms> Alrighty
17:10:10 <samkottler> frankieonuonga agreed to be the rel-eng rep a while back
17:10:18 <jzb> number80: what does that entail?
17:10:41 <samkottler> jzb: it'd mainly be scripting stuff to upload to public clouds
17:10:45 <samkottler> tools > humans
17:10:47 <gholms> I'm not trying to stop you or anything; I just want to have a clear picture.
17:11:31 <number80> jzb: plus improving general rel-eng process with more automation
17:11:43 <mattdm> yeah there is a plan to have image uploading be automatic.
17:11:50 <samkottler> it's also possible we could get dgilmore access without signing the document, but that's a whole other discussion
17:13:03 <number80> i'd say no, as it would force someone else to step up into rel-eng
17:13:30 <samkottler> well we should have someone else doing it regardless, but I was just putting that out on the table
17:15:15 <mrunge> esp. when thinking about release cycles, I'd love to see more automation
17:15:37 <rbergeron> automate all the things!
17:15:45 * rbergeron uses overused phrase
17:15:46 <samkottler> #topic +1
17:15:53 <samkottler> #undo
17:15:53 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x4c516d0>
17:15:55 <samkottler> +1
17:15:57 * rbergeron lulz
17:16:01 <gholms> Heh
17:16:02 <geppetto> :)
17:16:33 <samkottler> #topic Fedora.next product branding
17:16:35 <samkottler> :)
17:17:06 <samkottler> did people get a chance to read the thread on the list?
17:17:17 <mattdm> Yeah -- didn't respond but read it.
17:17:54 <jzb> I threw something out as a starter, I got one reply and I think we were largely saying the same things but slightly differently.
17:18:00 <mattdm> Are we generally in agreement with
17:18:02 <mattdm> Fedora Cloud provides a customizable base image and tools for developing
17:18:04 <mattdm> scale out applications on public and private clouds.
17:18:11 <mattdm> as our overall product?
17:18:14 <number80> yup
17:18:54 <number80> i wished that we added an emphasis on the devops side, but it's only a wording issue
17:19:11 <samkottler> the devops side in what respect?
17:19:18 <samkottler> ephemeralization of infrastructure?
17:19:43 <mattdm> I can get on board with that, although I'm also open to the idea of picking something more specific for the application scale-out approach and focusing around that
17:20:01 <mattdm> eg openshift and/or docker.
17:20:51 <samkottler> I think one thing that ubuntu has done really well in the cloud space is make their stuff extremely general purpose
17:21:06 <juergh> samkottler: +1
17:21:08 <number80> samkottler: not sure, i'm understanding that expression
17:21:31 <mattdm> whereas on the other hand, coreos goes the other way and basically comes batteries-included for a specific purpose.
17:22:01 <number80> It's more about providing tools from end to end of the process: the developer, the operator should use the same image
17:22:04 <mattdm> If I am alone in this, then we can just move on, because I think we can also do general purpose in a very succesful way.
17:22:10 <samkottler> number80: the ubuntu images can run docker, be ephemeral with the latest stuff, are a nice openstack guest standalone, etc.
17:22:20 <number80> samkottler: so we agree ;)
17:22:36 <samkottler> number80: yep, totally
17:23:35 <mattdm> overall, there's a tension between being able to do all of the things and being tailored to do one well. For example, normally one wouldn't want libvirt on a guest image, but that infrastructure will be necessary for selinux-protected docker, so we will want it for that...
17:23:53 <samkottler> mattdm: I don't mind aligning ourselves with certain other projects, but I thnink it's challenging to provide general, widespread value if we do
17:24:01 <mattdm> but it's a _big_ thing to add, so should probably be on the image itself for docker use, rather than installed with cloud-init or otherwise.
17:24:41 <samkottler> I almost feels like we need spins, but for cloud images
17:25:02 <mattdm> samkottler "library of cloud images". yes.
17:25:05 * rbergeron nods
17:25:15 <gholms> Thankfully lots of clouds make image customization a snap, too.
17:25:23 <jzb> samkottler: +1
17:26:29 <samkottler> so then we can produce a base, small image
17:26:36 <samkottler> and other stuff with the "value add" baked in
17:26:49 <samkottler> if you need a multi-tenant docker env, we've got that
17:26:50 <samkottler> etc.
17:26:57 <mrunge> well, I assume, that will confuse users to have a broad library of cloud images
17:27:16 <mrunge> so I'm -1 for (against) specialized images
17:27:27 <number80> the same
17:27:41 <samkottler> confuse users in what way?
17:27:45 <jzb> mrunge: they expect that, especially on AWS
17:27:45 <samkottler> they won't know which one to use?
17:27:57 <number80> i'd rather make it easy to build custom images and have a very bare one
17:28:15 <jzb> number80: we would, but also easy to use off-the-shelf images for specific things.
17:28:16 <mrunge> yeah, or if they see a list of 20 images, what do they do?
17:28:31 <mattdm> jzb +1 to off-the-shelf.
17:28:37 <jzb> mrunge: they pick the one that has the description that matches what they want
17:28:55 <mrunge> jzb, who reads docs?
17:28:55 <jzb> mrunge: this is not uniformed desktop users, this is developers who should be capable of reading a description and picking.
17:29:06 * gholms notes that we had this exact argument with the old spin download page
17:29:14 <samkottler> how many users are able to respin their own images without learning a significant amount of stuff
17:29:18 <jzb> mrunge: the people who choose from umpty-billion different AWS images based on Ubuntu?
17:29:23 <samkottler> remember that we're engineering for the 99% here :)
17:29:27 <gholms> samkottler: In AWS, all of them.
17:29:30 <samkottler> not the people who are in a working group :)
17:29:32 <gholms> Not sure about others.
17:29:40 <number80> jzb: from experience, specialized images always ends up with a lot of unused stuff for 90% of users
17:29:42 <geppetto> I think both extremes will be a bad idea … you don't want N people all "customizing" the same base into roughly the same baked in image.
17:29:48 <samkottler> gholms: that's not really true, though
17:29:53 <juergh> what about the effort to maintain a whole set of image vs. a bare image and some tools to customize it?
17:30:07 <samkottler> juergh: yep, that's basically what's being proposed
17:30:10 <juergh> think security updates and the likes.
17:30:12 <geppetto> Also the customizing can't be bugfree … which is a giant negative freeroll.
17:30:13 <samkottler> we'll keep the base image around
17:30:22 <jzb> number80: from experience with... images running in the cloud?
17:30:23 <samkottler> geppetto: mhm
17:30:50 <jzb> number80: this is our "competition"
17:30:51 <samkottler> number80: if the people don't need the stuff on top, then they just use the base image
17:30:52 <jzb> http://cloud-images.ubuntu.com/locator/ec2/
17:31:23 <jzb> https://aws.amazon.com/marketplace
17:31:27 <number80> jzb: yup, at $dayjob, i'm doing a lot of SaaS migration :/
17:31:31 <mattdm> So, thinking of the docker use case (just because that's what I'm working with), it's really awesome if there is a pre-made image that I can just launch or download+launch.
17:31:38 * mrunge needs to step out and will come back later
17:31:49 <number80> samkottler: +1
17:32:11 <mattdm> jzb but the cloud-images-locator is just the same as http://fedoraproject.org/en/get-fedora-options#clouds
17:32:36 <juergh> In my experience partners take a bare image, customize it, snapshot it and make that image available to their end users. There's alway some customization necesseray whether you start from a bare image or a specialized iamge.
17:32:59 <juergh> I'm not sold on customized images.
17:33:00 <geppetto> jzb: Is it obvious to other people how all those top 8 entries are different from each other?
17:33:05 <gholms> samkottler: You'vr seen how ridiculously easy EC2's console makes customizing an image, right?
17:33:17 <jzb> mattdm: similar, but my point is that people are capable of navigating things
17:33:41 <mattdm> gholms ridiculous in what sense? :)
17:34:07 <jzb> geppetto: I would hope if someone is doing app development and making some form of informed decision they are capable of reading a description and choosing.
17:34:19 <jzb> geppetto: also, this should not be a bare "the only thing they have is this page" situation
17:34:25 <samkottler> gholms: I wouldn't exactly say that
17:34:33 <jzb> geppetto: once we have soome customized images, we should be promoting them
17:34:34 <samkottler> most people don't build their own AMI's
17:34:54 <gholms> mattdm: Easy enough that I've got people from developers to graphic designers who figured it out on their own.  ;)
17:34:56 <jzb> geppetto: e.g. "hey, wanna run docker on Fedora, use <link>"
17:35:16 <gholms> samkottler: From scratch, of course not.  But customizi a base image is another story.
17:35:27 <jzb> geppetto: I think we'll put ourselves at a disadvantage having only a base image without any additional value-add images.
17:35:32 <samkottler> again, let's think about actual users
17:35:37 <samkottler> not us, but actual people :)
17:35:38 <jzb> though we should point loudly to the default
17:35:42 <geppetto> jzb: Sure.
17:35:45 <jzb> samkottler: hey, I think.
17:35:55 * jzb thought he was an actual people.
17:36:11 <number80> jzb: for our target, the barest image is itself a value
17:36:16 <gholms> samkottler: I really wish I could show you my data on this.  :(
17:36:20 <mattdm> My viewpoint is that we have a pretty decent generic base image right now, and it's not getting very much traction.
17:36:21 * gholms cries
17:36:44 <gholms> mattdm: You know, that's a good point.
17:36:44 <jzb> mattdm: +1
17:36:46 <samkottler> gholms: I don't doubt that it's true, my point is that there are a lot of people who want to use an image without having to "rebake" it
17:37:04 <number80> mattdm: we lacks maintained application stacks :(
17:37:05 <gholms> samkottler: Makes sense
17:37:20 <mattdm> number80 +1 yes.
17:37:27 <number80> i'd rather rely on easily installable SCL than a bunch of images
17:37:41 <samkottler> telling users 'here, launch this AMI and you'll have docker/openshift/whatever' is huge
17:37:55 * gholms nods
17:38:01 <jzb> number80: let me see if I'm understanding this
17:38:05 <frankieonuonga> i am in guys
17:38:08 <frankieonuonga> sorry i am late
17:38:09 <mattdm> what if we kept the library small? three or four things in addition to the base, rather than 20?
17:38:13 <jzb> number80: you feel that offering 20 images is confusing
17:38:22 <jzb> number80: but offering one + shuttling them off to SCLs is not?
17:38:22 <number80> samkottler: we could add a script in user-data for that
17:38:29 <samkottler> 20 images is also insane to test
17:38:38 <samkottler> < 5 is perfect IMO
17:38:47 <number80> jzb: a base image and users are free to install any SCL they need
17:39:03 <jzb> number80: again, that's less confusing than offering it pre-baked?
17:39:07 <geppetto> samkottler: +1 … extremes of both cases will be pretty bad, IMO.
17:39:13 <jzb> when I can just spin up an Ubuntu image that has what I want?
17:39:43 <mattdm> so, proposal: base image, plus tools for extending (including application stack work), plus 2-4 images preconfigured for specific uses.
17:39:49 <samkottler> mattdm: +1
17:39:49 <jzb> geppetto, samkottler I am in agreement that 20 may be a bit much
17:39:56 <geppetto> mattdm: +1
17:40:00 <jzb> maybe 4 or 5 would be the ideal situation
17:40:26 <jzb> and if we start getting traction, perhaps the larger community will start building + offering more.
17:40:30 <gholms> Not to mention we'd have a lot easier time maintaining and testing just a few images.
17:40:33 <number80> jzb: yes, most of the time, your image will require frying anyway
17:40:43 <number80> n images = n times more QA
17:40:53 * rbergeron thinks there is a healthy balance between gholms's thoughts and samkottler's
17:41:17 <gholms> What if we start with just a few and see where that takes us?
17:41:21 <jzb> so, mattdm's proposal: ^^
17:41:27 <geppetto> jzb: My guess is that it'd be a mistake to go above ~7 pre. baked images (roughly what people can remember, easily)
17:41:34 <samkottler> yeah, a few seems perfect for now
17:41:35 <frankieonuonga> i am +1 on gholms idea
17:41:40 <jzb> "base image, plus tools, plus 2-4 images preconfiguted for specific uses"
17:41:40 * rbergeron is also pretty sure that the number of folks that take a base image and then snapshot it after updating it in their own way is pretty large
17:41:48 <number80> if we have people to help maintaining more images, why not, but the main goal of fedora.next is to reduce the scope to get better products
17:41:54 <samkottler> if people like them then we can consider making more
17:41:55 <juergh> rbergeron: exactly
17:42:06 <geppetto> If everyone could stop re-proposing what mattdm said, and just +1 that'd be nice ;)
17:42:08 <number80> samkottler: +1
17:42:14 <jzb> so I'm +1 to mattdm / gholms
17:42:25 <jzb> geppetto: +1
17:42:35 * rbergeron just +1s the last 12 things said :)
17:42:37 <juergh> who/what's do decide what those additional images contain?
17:42:37 <frankieonuonga> i have already voted but just to clarigy gholms +1
17:42:48 * jzb +1's rbergeron
17:42:59 <jzb> (I think we have consensus)
17:43:18 * gholms +1s jzb just because  :P
17:43:28 <mattdm> juergh all of us, and depending on who wants to work on what.
17:43:44 <samkottler> #agreed we'll produce a base image, with tools, and 2-4 images preconfigured for specific uses
17:43:49 * samkottler is excited about this
17:44:35 <mrunge> yeah, sounds good to me, the fewer, the better
17:45:06 <rbergeron> well - the worst that can happen is that we can find out that they're all wildly popular
17:45:21 <rbergeron> or that we were wrong about he popularity of one or another and ... figure out how to tune it / make it better / drop it
17:45:27 <rbergeron> learning ftw :)
17:45:42 <samkottler> agreed
17:45:56 <mattdm> rbergeron yes. and we need better metrics. we do not really have those right now. that might be a whole 'nuther issue.
17:46:06 <samkottler> next we need to figure out which ones we'll produce, but we can take that to the list
17:46:19 <number80> i suggest polls
17:46:24 * samkottler has a feeling some people will have opinions about that
17:47:07 <number80> i'd rather go ask actual users than relying on how own distorted perception :o)
17:47:13 <number80> well, mine is distorted
17:47:24 <samkottler> number80: well before we can poll we need some options, but yeah an end-user poll would be great
17:47:25 <mattdm> good polls are hard / expensive.
17:47:47 <frankieonuonga> totally agree with number80 but my only problem is how do we gather pols..do we let people vote as they download an image ?
17:47:48 <samkottler> also, remember that most of our target users currently aren't in the community :)
17:47:57 <mattdm> but could we bracket that for now and come back to it? there's more agenda to get through :)
17:48:03 <jzb> mattdm: +1
17:48:07 <frankieonuonga> mattdm: we could poll on the site and collect results on mysql
17:48:09 <mrunge> +1
17:48:12 <mattdm> the topic right now was product branding
17:48:15 <number80> +1
17:48:26 <mattdm> And this question was the big part of that that I felt was open
17:48:42 <mattdm> other than that, I think jzb's initial response was good except I would s/Docker/CoreOS/g
17:48:46 <samkottler> yeah, the PRD and branding docs will be much easier now
17:49:41 <jzb> mattdm: can we +CoreOS?
17:49:42 <samkottler> so should we take the branding document back to the list and move on?
17:49:56 <jzb> but I'm easy, s/Docker/CoreOS/g works too
17:50:24 <rbergeron> isn't coreOS like a ... whole different nut to crack from docker
17:51:10 <mattdm> Fedora happily includes Docker. CoreOS is a platform for Docker deployment + some other stuff, which is basically directly in competition.
17:51:19 <mattdm> friendly, open source competition :)
17:51:42 <number80> may the best win
17:52:04 <jzb> as long as it's us
17:52:08 <jzb> :-)
17:52:12 <frankieonuonga> :-)
17:53:09 * rbergeron looks back to samkottler's branding document question
17:53:24 <mattdm> yeah, +1 to back to the list and next item
17:53:38 <samkottler> #topic put together a team/plan to work on the PRD
17:54:03 <frankieonuonga> just as a reminder...what was PRD again ?
17:54:09 * rbergeron poked away some lsat week.
17:54:17 <samkottler> https://fedoraproject.org/wiki/Cloud_PRD
17:54:33 * samkottler is planning on working on it on friday and maybe tomorrow depending on how bored he gets
17:54:35 <rbergeron> but slowly. and having help would be teh awesomes so i am not feeling sad and lonely and wondering if i'm doing the right thing :)
17:55:13 * frankieonuonga offers to help samkottler
17:55:17 <jzb> rbergeron: will try to poke at it more this weekend
17:55:29 <jzb> rbergeron: will be doing the traditional gorging tomorrow and Friday
17:55:40 <rbergeron> jzb: TURKEEEEEEE
17:55:43 <samkottler> remember that we agreed to try and get it done by december 15th
17:55:47 <samkottler> which is kinda soon
17:56:02 <samkottler> rbergeron: don't remind me
17:56:04 <number80> rbergeron: i did some proof-reading this afternoon, and i plan to import openstack personas so we could grok our own personas
17:56:24 <frankieonuonga> we use cloud stack where i work so i can do that
17:56:39 <jzb> frankieonuonga: +1
17:56:47 * jzb says, wearing CloudStack PMC hat.
17:56:52 <samkottler> do we want individual personas for each private cloud impl?
17:57:06 <rbergeron> number80: cool, thanks
17:57:12 <rbergeron> samkottler: yeah. it's very soon :)
17:57:28 <number80> jzb: i prefer my yellow shiny eucalyptus t-shirt :P
17:57:37 <rbergeron> frankieonuonga: you just made jzb and ke4qqq smile, lol
17:57:46 <rbergeron> number80: that's because it's an epic shirt
17:57:51 <number80> \o/
17:57:53 <rbergeron> samkottler: impl?
17:57:56 <frankieonuonga> :-) always a pleasure to ...plus ke4qqq is a huge help
17:58:03 <rbergeron> sorry, my head isn't right
17:58:08 <frankieonuonga> thanks mate
17:58:22 <jzb> samkottler: probably
17:58:58 <frankieonuonga> I would say 2 people in each
17:58:58 <number80> sorry, let's focus
17:59:04 <frankieonuonga> if possible
17:59:44 <samkottler> the PRD is just the kind of thing that requires hammering away on
17:59:44 <number80> (besides fesco meeting in one minute)
18:00:01 <number80> samkottler: +1
18:00:09 <samkottler> anyone have anything else to add on the PRD?
18:00:32 <samkottler> rbergeron: implementation
18:00:39 <rbergeron> samkottler: AHHHH
18:01:47 <samkottler> can we bump the release/lifecycle discussion to next week?
18:01:58 <number80> +1
18:02:02 <mrunge> +1
18:02:05 <mattdm> samkottler yes that's fine..
18:02:08 <jzb> samkottler: maybe start on email?
18:02:08 <frankieonuonga> +1
18:02:10 <jzb> but +1
18:02:10 * mattdm has fesco meeting now
18:02:11 <number80> maybe kickstarting the discussion on the list
18:02:21 <samkottler> mattdm: can you kick that off on the list?
18:02:28 <mattdm> samkottler yep
18:02:41 <samkottler> mattdm: danke!
18:02:49 <samkottler> #topic open floor
18:03:09 <samkottler> anyone got anything else before we wrap up?
18:03:14 <frankieonuonga> yes
18:03:14 <sgallagh> Dangerous topic: dividing line of Server and Cloud? (Sorry if this was discussed earlier, just got here)
18:03:34 <frankieonuonga> I will wait for sgallagh to finish then i come in with mine
18:03:41 <mrunge> oh yes, good question
18:04:53 <mrunge> and sgallagh IMHO we had that very briefly on the cloud-ml, but didn't come to any conclusion
18:05:00 <frankieonuonga> I want to ask if we have some docs for the server side to find out what their limit is
18:05:02 <sgallagh> So it came up on yesterday's call that it's somewhat ambiguous
18:05:08 <mattdm> It's looking to me that there is going to be some overlap
18:05:12 <sgallagh> s/call/meeting/
18:05:15 <mattdm> which is not necessarily bad.
18:05:17 <sgallagh> As there should be
18:05:23 <sgallagh> But how much?
18:05:59 <frankieonuonga> I personally think that we need to go in a few months before we know exactly what is happening
18:06:05 <frankieonuonga> but that is just me
18:06:20 <samkottler> sgallagh: it seems like we need to establish where we have the potential to overlap before we can figure out how much overlap is okay?
18:06:41 <mattdm> possibly a lot, at the core level. We're also going to focus on prebaked images for things like docker and openshift
18:06:45 <sgallagh> samkottler: We covered that somewhat in our Server WG meeting yesterday.
18:07:02 <samkottler> sgallagh: I'll re-read the log then, thanks
18:07:03 <sgallagh> https://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-meeting/ is a good write-up of that meeting
18:07:10 <mattdm> also, I think that we will be somewhat concerned more with _language_ stacks and server maybe more with _application_ stacks?
18:07:12 * samkottler will make a point of attending those meetings
18:07:36 * frankieonuonga is lost but will figure it out
18:07:52 <sgallagh> mattdm: We're focusing our intentions pretty heavily around the ability to assign "roles" to a server
18:07:57 * number80 gotta go (office building is closing)
18:08:13 <sgallagh> At a high level "i.e. This machine is a domain controller", "This machine is a PostgreSQL server"
18:09:13 <frankieonuonga> by the way guys I am sorry . I know I had promised the packages for about 1 week ago but I have been badly busy at work. anyway happy to say that Samkottler has been a great help so i should be able to finish by end week. sorry again
18:09:43 <mrunge> and how fits e.g oVirt in this figure?
18:10:10 <mrunge> server based on small images
18:10:47 <mrunge> so, somehow oVirt is a classical data-center product
18:10:52 <mrunge> == a server product
18:11:24 <mrunge> but on one side totally based on small images (for compute nodes)
18:11:33 <mattdm> ovirt node vs. ovirt [whatever the not-node-part-is-called]
18:11:54 <mattdm> sgallagh Another differentiator might be image-based deployment vs. kickstart deployment.
18:11:55 * samkottler likes the idea of operating under the premise that server owns the hypervisor and we own the guest
18:12:05 <jzb> samkottler: +1
18:12:18 <frankieonuonga> +1 samkottler
18:12:30 <mrunge> samkottler, in the oVirt case, we would own both
18:12:40 <mrunge> and the same applies to server WG
18:12:42 <mattdm> who owns 'postgresql server' in that model?
18:12:51 <sgallagh> mattdm: I'm not sure if that differentiates the products really
18:13:13 <sgallagh> (Referring to kickstart vs. image)
18:13:26 <sgallagh> To me, the product is the result of that action
18:13:32 <samkottler> mrunge: no in the ovirt case we'd own neither
18:13:59 <samkottler> mattdm: the server WG would own the things that aren't cloud related
18:14:20 <samkottler> so we could own cloud-init, virtio stuff (maybe?) and they would own all the 'regular' packages
18:14:31 <frankieonuonga> i beg to differ...to some extent i think that our images in some cases are used as servers.
18:14:37 <gholms> Seems reasonable
18:14:38 <frankieonuonga> but i might be wrong
18:15:00 <sgallagh> samkottler: I generally agree on the hypervisor vs. guest thing
18:15:09 <sgallagh> Except of course for the tenancy case...
18:16:00 <sgallagh> i.e. virt-on-virt
18:16:22 <jzb> sgallagh: virt-on-virt?
18:16:34 <samkottler> frankieonuonga: oh yeah of course, we're mainly talking about where the server WG's role ends and ours begins
18:16:41 <samkottler> and I guess then where theirs starts again
18:16:44 <sgallagh> jzb: I set up a virtualized cloud and then rent you the ability to do virt inside my cloud
18:16:54 <samkottler> jzb: russia doll virt
18:16:58 <samkottler> russian doll**
18:17:11 <mrunge> jzb, e.g the undercloud-overcloud thing in OpenStack
18:17:19 <mrunge> jzb, named TripleO
18:17:32 <sgallagh> where virt may be one or more of "kvm, xen, lxc, docker..."
18:17:59 <samkottler> sgallagh: so basically you'd own the 'lowest' hypervisor
18:18:01 <jzb> ah
18:18:10 <mrunge> I'm not sure, if we can divide them at all
18:18:17 <samkottler> mrunge: tripleo is a whole other thing from russian doll virt
18:18:25 <mrunge> (I mean server and cloud)
18:19:13 <mrunge> samkottler, I don't think so.
18:19:31 <mrunge> nevertheless, this is nothing we can decide right now
18:19:49 <samkottler> mrunge: tripleo is using openstack to provision physical hardware
18:19:55 <samkottler> mrunge: and then install a hypervisor on top
18:20:17 <samkottler> vs. virtualizing on top of a hypervisor and then using that hypervisor to run another guest inside of it
18:21:21 <mrunge> samkottler, it's not necessarily the case
18:21:30 <samkottler> do we actually want to vote on something related to this?
18:21:32 <mrunge> but usually folks will implement it that way
18:22:35 <samkottler> frankieonuonga: you had something to bring up?
18:22:41 <frankieonuonga> yeah
18:22:55 <frankieonuonga> I am sorry . I know I had promised the packages for about 1 week ago but I have been badly busy at work. anyway happy to say that Samkottler has been a great help so i should be able to finish by end week. sorry again
18:23:17 <frankieonuonga> i thought it might be easier but there are some things i had over looked
18:23:21 <frankieonuonga> so i am doing what i can
18:23:40 <samkottler> no worries - let us know where/when you need help :)
18:23:52 <samkottler> #endmeeting