Thanks everyone who was able to make it to the meeting today! For those who weren't able to make it, here are few important links:

Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting-... Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting-... Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting-... Log (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting-...

Here's a summary of the meeting (link to the HTML and text versions above):

========================================== #fedora-meeting-1: Cloud WG weekly meeting ==========================================

Meeting started by samkottler at 17:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting-... .

Meeting summary --------------- * rollcall (samkottler, 17:00:37) * LINK: https://fedorahosted.org/cloud/ticket/4 (mattdm, 17:04:18)

* update on GCE legal and packaging things (samkottler, 17:05:03) * email shk@redhat.com if you want to get added to the trusted testers program or want to see the language associated with it (samkottler, 17:05:58) * LINK: http://fedorapeople.org/cgit/skottler/public_git/google-compute-engine-packa... (samkottler, 17:06:59)

* Fedora.next product branding (samkottler, 17:16:33) * LINK: http://cloud-images.ubuntu.com/locator/ec2/ (jzb, 17:30:52) * LINK: https://aws.amazon.com/marketplace (jzb, 17:31:23) * AGREED: we'll produce a base image, with tools, and 2-4 images preconfigured for specific uses (samkottler, 17:43:44)

* put together a team/plan to work on the PRD (samkottler, 17:53:38) * LINK: https://fedoraproject.org/wiki/Cloud_PRD (samkottler, 17:54:17)

* open floor (samkottler, 18:02:49) * LINK: https://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-m... is a good write-up of that meeting (sgallagh, 18:07:03)

Meeting ended at 18:23:52 UTC.

Action Items ------------

Action Items, by person ----------------------- * **UNASSIGNED** * (none)

People Present (lines said) --------------------------- * samkottler (103) * jzb (52) * mattdm (49) * number80 (38) * frankieonuonga (29) * mrunge (27) * gholms (26) * rbergeron (25) * sgallagh (17) * geppetto (10) * juergh (8) * zodbot (5)

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-packa... 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-m... 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