Thanks everyone who was able to make it to the meeting yesterday! For those who weren't able to make it, here are few important links: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeting-1.2014-01-15-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeting-1.2014-01-15-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeting-1.2014-01-15-17.01.log.html Log (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeting-1.2014-01-15-17.01.log.txt Here's a summary of the meeting (link to the HTML and text versions above): 17:01:57 <samkottler> #startmeeting cloud WG weekly meeting 17:01:57 <zodbot> Meeting started Wed Jan 15 17:01:57 2014 UTC. The chair is samkottler. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:08 <jzb> howdy 17:02:25 <samkottler> #chair rbergeron mattdm number80 geppetto jzb 17:02:25 <zodbot> Current chairs: geppetto jzb mattdm number80 rbergeron samkottler 17:02:45 <samkottler> welcome to 2014's first official meeting :-) 17:02:58 * samkottler wonders if special guest davidstrauss is gonna join us 17:03:30 <samkottler> #topic rollcall 17:03:45 <jzb> jzb is here 17:03:48 <samkottler> \o/ 17:03:53 <number80> .fasinfo hguemar 17:03:55 <zodbot> number80: User: hguemar, Name: Haïkel Guémar, email: karlthered@xxxxxxxxx, Creation: 2006-07-18, IRC Nick: number80, Timezone: Europe/Paris, Locale: en, GPG key ID: 41CF9CEA, Status: active 17:03:58 <zodbot> number80: Approved Groups: +packager cla_fedora cla_done fedorabugs ambassadors cla_fpca gitbeefymiracle 17:03:59 <samkottler> .hellowmynameis skottler 17:04:04 <samkottler> .hellomynameis skottler 17:04:06 <zodbot> samkottler: skottler 'Sam Kottler' <skottler@xxxxxxxxxx> 17:04:11 * samkottler struggles 17:04:22 <jzb> .hellomynameis jzb 17:04:22 <mattdm> .fasinfo mattdm 17:04:27 <zodbot> jzb: jzb 'Joe Brockmeier' <jzb@xxxxxxxxxx> 17:04:30 <zodbot> mattdm: User: mattdm, Name: Matthew Miller, email: mattdm@xxxxxxxxxx, Creation: 2005-04-13, IRC Nick: mattdm, Timezone: US/Eastern, Locale: en, GPG key ID: 72CF3A1B, Status: active 17:04:33 <zodbot> mattdm: Approved Groups: @gitdockerfiles gitspin-kickstarts +gitspins @gitcloud-image-service fi-apprentice gitcloud-kickstarts cla_done fedorabugs packager ambassadors cla_fedora cla_fpca 17:04:41 <jzb> hey! finally found a way to get it to limit to matching my username... 17:05:05 <number80> i didn't knew that command too :) 17:05:29 <rbergeron> .hellomynameis slim_shady 17:05:31 <zodbot> rbergeron: Sorry, but you don't exist 17:05:32 <geppetto> .hellomynameis geppetto 17:05:35 <rbergeron> darnit 17:05:37 <zodbot> geppetto: Sorry, but you don't exist 17:05:42 <geppetto> cool :) 17:05:44 <mattdm> lol 17:05:49 <sgallagh> geppetto: Has to be your FAS ID 17:06:04 <samkottler> this meeting has entered the land of meta 17:06:08 <sgallagh> .hellomynameis sgallagh 17:06:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@xxxxxxxxxx> 17:06:19 <geppetto> .hellomynameis james 17:06:21 <zodbot> geppetto: james 'James Antill' <james.antill@xxxxxxxxxx> 17:07:14 <samkottler> #topic PRD update and pending issues 17:07:23 <samkottler> it's due on the 20th 17:07:38 <mattdm> it's looking a lot better than it was a week ago! 17:07:39 <samkottler> and there are still some things we need to talk with the server WG about, sgallagh is here so maybe we should do that now? 17:07:55 <samkottler> yep, it's definitely shaping up 17:08:02 <samkottler> I've been trying to spend an hour or so per day on it 17:08:14 <mattdm> awesome. 17:08:42 <mattdm> I'm for starting with talking iwth sgallagh re server/cloud 17:08:48 * number80 gives a kudos to samkottler 17:08:51 <samkottler> we need to figure out the features we're gonna support 17:09:12 <samkottler> the use cases are mostly done, which was a big hurdle 17:10:01 <rbergeron> features to support or features to enable to enable the .. use cases 17:10:02 <mattdm> Do we want to try to hash out some specific thigns while we have everyone here 17:10:11 <mattdm> or should we look at some of the bigger picture things? 17:10:26 <samkottler> rbergeron: yes 17:10:35 <rbergeron> i'm not opposed, though it might be useful to know if any of those things are influenced by the server-ish stuff sgallagh is here for? 17:10:36 <samkottler> both 17:10:49 <samkottler> yeah, let's talk to sgallagh first :-) 17:10:55 <mattdm> sgallagh go! 17:10:57 * sgallagh feels honored 17:11:34 <number80> go sgallagh // right syntax 17:11:39 <sgallagh> The Server WG had its hopefully-final PRD meeting yesterday. We invited jzb and number80 to represent Cloud interests 17:11:59 * sgallagh really wants to make a Zork joke right now 17:12:46 <jzb> sgallagh: what's stopping you? 17:13:19 <sgallagh> I'm stuck in a maze of twisty cubicles, all alike... 17:13:51 <sgallagh> Ok, so there was a lot of discussion yesterday about where the dividing line is for things like OpenStack and OpenShift 17:15:15 <mattdm> I think that right now at least, cloud is focused on guest images and excludes openstack execution nodes 17:15:25 <sgallagh> that was our sense as well 17:15:39 <mattdm> that might change in the future, but leaves "runs in virt" as a common thread 17:15:58 <sgallagh> we proposed that OpenStack nodes should be a Server Role, possibly contributed by this group 17:16:17 <sgallagh> but "owned" by server 17:16:39 <samkottler> I think that's always been the assumption 17:16:48 <samkottler> the hypervisor'ish stuff would be owned by server 17:17:03 <mattdm> any dissent? speak now. :) 17:17:32 <sgallagh> That's been my assumption, but there was a lot of discussion about it yesterday 17:18:09 <sgallagh> It's also ambiguous where "managing an OpenShift deployment" belongs. 17:18:10 <jzb> sgallagh: more or less, though I sort of envisoned OpenStack nodes as closer to the server side than cloud side. 17:18:39 <sgallagh> jzb: I agree, but it's fair to say that the implementation will need to involve Cloud heavily 17:18:53 <jzb> sgallagh: indeed 17:19:15 <mattdm> I thik there's room to have some overlap. You can do e.g., a web server or web application in _either_ a cloud paradigm (<-bingo!) or the traditional server way. 17:19:22 <sgallagh> Why don't we turn the conversation around a bit. I had jzb and number80 in our meeting to answer our questions. Why don't you raise your own for us. 17:19:32 <jzb> yay! 17:19:38 * jzb tries to think of a stumper 17:20:05 <sgallagh> Where do you guys see ambiguity in our missions? 17:20:08 <rbergeron> ask something about configuration management or orchestration tools :) 17:20:19 <jzb> that is a good Q 17:20:28 <sgallagh> rbergeron: Config management is clearly in our laps 17:20:51 <sgallagh> "Orchestration tools" is a harder question 17:21:09 <rbergeron> I think the biggest source of ambiguity is that people equate "openstack" (and all the others) with cloud and i can see how that might be cause for misdirected questions. 17:21:09 <mattdm> sgallagh I think some of the ambiguity is that we're both doing "here's a base thing which can be adapted for different roles". 17:21:12 <samkottler> stuff like mesos blurs the lines 17:21:16 <sgallagh> We've got a use case for orchestration of containers, but that's not a complete answer 17:21:17 <mattdm> rbergeron that too 17:21:38 <mattdm> for server, it's the base platform plus application stacks 17:21:46 <mattdm> for cloud it's... well, possibly the same thing. 17:21:47 <sgallagh> "Server Roles" 17:22:26 <rbergeron> Logging? Things like checkpoint/restore? Storage (gluster or other cloud-ish storage)? Are we going to try and ... match up where we can on things? Or... "you can go your own wayyyyyyyyyyyy" 17:23:13 <sgallagh> logging is a much more complex question than a single word. 17:23:25 <samkottler> I think we can safely draw the line at 'do you need this thing on a physical machine' 17:23:32 <samkottler> logging is a yes and storage is a yes 17:23:35 <sgallagh> Checkpoint/restore is probably not all that useful to Cloud images, since you're aiming for mostly-disposable anyway, yes? 17:23:37 <samkottler> at least in my view 17:23:47 <mattdm> sgallagh right 17:23:50 <samkottler> yeah 17:24:01 <jzb> samkottler: if the users are doing it right 17:24:01 <mattdm> I think we want to keep the line more at cattle/pets than hw/virt 17:24:01 <rbergeron> sgallagh: processes running and such? i don't know 17:24:09 <samkottler> although people run stuff like...database servers in the cloud, too 17:24:10 <rbergeron> moving vm's and such 17:24:10 <jzb> sorry that was for sgallagh 17:24:26 <jzb> sgallagh: from working on CloudStack, I found a lot of questions around snapshotting/restore. 17:24:50 <samkottler> people do care about their instances being easy to restore 17:24:54 <number80> (sorry, got disturbed by coworkers) 17:24:59 <jzb> sgallagh: it's also used a lot to create a golden image. Spin one up, modify, then snapshot -> template 17:25:04 <samkottler> even just from a convenience perspective 17:25:13 <samkottler> jzb: :/ but yeah, common 17:25:34 <mattdm> but we expect the cloud env to hande that, right? 17:25:40 <jzb> in other words, ideally, no - we generally not care. In the real world, we do. 17:25:44 <jzb> mattdm: yes. 17:25:48 <samkottler> it's a hypervisor thing anyhow 17:26:09 <number80> yup 17:26:10 <jzb> samkottler: it's a hz thing except that the IaaS exposes the hz features. 17:26:17 <sgallagh> I'm not sure the PRDs need to be exhaustive either 17:26:26 <rbergeron> jzb: ah, that's a dandy point there 17:26:33 <sgallagh> It's probably worth noting that individual implementation goals can be solved through collaboration 17:27:04 <samkottler> jzb: like in the case where a guest requests a snapshot of itself? 17:27:14 <sgallagh> I'm not sure it's sensible or feasible to enumerate every possible aspect of the implementation. 17:27:30 * rbergeron needs to snapshot/restore her soda. where did it disappear to? ugh 17:27:39 <jzb> samkottler: I was thinking when a user uses the API or UI to create one. 17:27:53 <rbergeron> sgallagh: just trying to make sure we're not missing anything significant in overlap so just suggesting All The Things 17:27:54 <sgallagh> I view "ownership" of these areas as more of shepherding than dictating. 17:27:57 <samkottler> let's move on with the general understanding of were the line stands 17:27:59 <jzb> samkottler: again, I ran into a lot of users who basically used the IaaS as Advanced Virtualization 17:27:59 <mattdm> sgallagh +1 17:28:03 <number80> sgallagh: +1 17:28:06 <jzb> sgallagh: +1 17:28:45 <mattdm> If we can do it without confusion, I would like to steer users who are interested in IaaS-as-server-in-the-sky towards using Fedora Server rather than the cloud image 17:28:52 <sgallagh> I'm sure as hell not going to make a decision on a major change to hypervisor tech without consulting this team, for example. 17:28:52 <mattdm> but that might be hard to message. 17:28:57 <samkottler> do we want to do a vote on the line or just move forward with everyone in agreement? 17:29:21 <jzb> mattdm: I always looked at it as, they can start using the tool the wrong way and learn to do it right 17:29:21 <sgallagh> Just as one more aside: 17:29:36 <sgallagh> One thing that came up yesterday that I'd like to have buy-in from both sides is this: 17:29:38 <jzb> mattdm: so if they adopt OpenStack/CloudStack/Euca, it makes it easier to learn the right habits eventually. 17:30:09 <sgallagh> We need to share a "Universe" package repository, so that if someone installs the base cloud image, they will be able to "yum install fedora-server-release" and have any and all capabilities that Server offers (such as Roles) 17:30:46 <sgallagh> The subtext being: we are not producing disparate Fedora repositories (excepting the install media) 17:31:02 <mattdm> Okay, that's an interesting one. Maybe we should make that explicit in the PRD? 17:31:03 <number80> separate repositories would only make things worse (think RPM hell dependencies) 17:31:18 <mattdm> I mean, yes, I think there needs to be a universal repo 17:31:33 <mattdm> the question is: is going from cloud base -> server an expected normal path? 17:31:35 <geppetto> sgallagh: So is the intention that people can/will be able to install multiple *-release packages? 17:31:35 <jzb> sgallagh: as yesterday, agreed 17:31:52 <jzb> sgallagh: I think there may have been some accidental FUD that the idea of separate repos even surfaced. 17:31:53 <mattdm> what about the other way around? (I think it might be okay to define this as a one-way path) 17:31:55 <sgallagh> geppetto: I don't want to make a general statement on that. 17:32:14 <sgallagh> I'm fine with "Cloud can become Server" and not the reverse (or Server->Workstation, etc.) 17:32:14 <mattdm> you can adopt one of your cattle as a pet. but you can't really send your kitty out to live in the herd. 17:32:40 <sgallagh> mattdm: My parents told me they sent my dog to the farm. Are you telling me they lied? 17:33:24 <sgallagh> jzb: Right, but the separate repos is related, but not the whole statement I was just making. 17:33:36 <geppetto> sgallagh: Why not server => cloud? 17:33:56 <jzb> mattdm: my cats agree 17:34:11 <samkottler> server to cloud makes perfect sense IMO 17:34:12 <sgallagh> geppetto: I'm not ruling it out. But I don't know if I see obvious value there, unless I misunderstand your target 17:34:18 <rbergeron> i may be confused here - i sort thought people were like 17:34:20 <rbergeron> moving from the server 17:34:21 <rbergeron> to the cloud 17:34:34 <samkottler> rbergeron: well the intermediate is just taking a server and putting it on kvm/xen 17:34:43 <rbergeron> samkottler: right, babysteps 17:34:58 * samkottler thinks a server to cloud path is necessary 17:35:03 <sgallagh> My initial statement was merely this: You want to virtualize/containerize/stick in public IaaS some of your critical infra. 17:35:09 <samkottler> which basically involves virtio drivers, cloud-init, whatever else 17:35:25 <number80> sgallagh: you mean having a p2v like tool ? 17:35:29 <sgallagh> You can spin up the Amazon Fedora Cloud instance and then easily make that become a Server instance with the frameworks we provide 17:35:48 <sgallagh> number80: Really not talking that level of detail at the moment. 17:36:10 <number80> ok 17:36:14 <mattdm> this is traditional server -> server-in-the-sky. that's fine, but server-in-the-sky isn't necessarily Fedora Cloud 17:36:17 <mattdm> is my thinking. 17:36:18 <sgallagh> Merely that a machine (virtual or not) installed from the Cloud Image can *become* a "full" Server install simply through yum/dnf/packagekit 17:36:45 <mattdm> in order to really migrate to take advantage of cloud computing, you rearchitect. 17:37:01 <number80> my POV is that fedora-cloud is basically a trimmed-down image on which you can install whatever "role" you wish too 17:37:12 <sgallagh> mattdm: Well, no matter what, you'll still probably want a fairly traditional Domain Controller and DNS environment 17:37:18 <sgallagh> But that's a different discussion 17:37:47 <jzb> number80: agreed, but there may also be roles that make sense only in the cloud. 17:37:49 <mattdm> number80 and Fedora Cloud provides some cloud-computing-focused roles, and a way to go to fedora server for roles that aren't necessarily covered but still always useful 17:37:59 <number80> jzb: +1 17:38:29 <samkottler> so assuming here's a universe what makes so directly separating the roles necessary? 17:38:53 <samkottler> I guess my disconnect is why I wouldn't say...install freeipa on a cloud instance just like I would on a regular box in a DC 17:39:25 <sgallagh> samkottler: You can. But we're (Server) going to be doing some additional packaging work to make role deployment simpler 17:39:25 <mattdm> okay, so: do we want to tie this more closely together and share the roles? 17:39:38 <sgallagh> But it's going to require additional infrastructure that you may or may not want. 17:39:52 <samkottler> sgallagh: ah okay that makes more sense now 17:40:15 <samkottler> so it'd basically expose comps to you or something? 17:40:22 <samkottler> whatever, I get the point, no need to dive so deep 17:40:26 <rbergeron> what are the pieces of a "role" exactly? 17:40:32 <rbergeron> wait, i'm slower than samkottler 17:40:33 <sgallagh> samkottler: Things like interaction with the Cockpit Project so that you could deploy the role with minimal interaction (just answer three questions and go) 17:40:36 <rbergeron> (obviously) 17:40:59 <rbergeron> is a role == set of packages known to work in a specific way? 17:41:05 <rbergeron> together to do something? 17:41:11 <sgallagh> rbergeron: Essentially yes. 17:41:22 <sgallagh> Though our definition of "set of packages" is currently intentionally vague 17:41:42 <sgallagh> Because people get hung up on packaging==rpm 17:41:56 <rbergeron> how does it overlap with something like ... heat templates 17:42:07 <sgallagh> FYI: https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Document_Draft#Featured_Server_Roles 17:42:12 <jzb> sgallagh: role == software required for a specific task? 17:42:22 <sgallagh> jzb: That's a better description, yes 17:42:36 <rbergeron> or .. docker containers for various pieces of things 17:42:43 <samkottler> rbergeron: it wouldn't orchestrate across-server stuff 17:42:50 <samkottler> just on a single node 17:42:57 <sgallagh> rbergeron: docker containers is one possible packaging implementation (and is being considered) 17:43:58 <rbergeron> samkottler: yeah, but i am just wondering about how to make the "known templating things" out there - which are basically all defining roles of some sort, just implementing them in ways where they can (or can't) be auto-magically scaled 17:44:46 <rbergeron> the perennial wordpress example - do we want a wordpress role (if that's what we're sort of thinking) to look the same as a heat template for wordpress, etc 17:44:49 <samkottler> rbergeron: wouldn't that be closer to config management's realm? 17:44:51 <rbergeron> or not really concerned with that at that point 17:45:10 <rbergeron> samkottler: "best tool for the job" - people are gonna do it however they want :) 17:45:32 <samkottler> I guess separating cfg mgmt from one-time ops isn't really something that you do in say...docker land 17:45:40 <sgallagh> rbergeron: Wordpress is probably not the sort of Role we'd (Server) be most interested in. 17:46:09 <sgallagh> From the Use Cases section of our PRD: Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server, OpenStack Hypervisor Node. 17:46:14 <rbergeron> sgallagh: i know, it's just a sample example . 17:46:36 <sgallagh> I'm pretty much entirely disinterested in treating specific applications as Server Roles 17:46:51 <sgallagh> (others on the WG may have a different opinion on that matter) 17:46:54 <rbergeron> i'm not going to be cruel and bring up triple-o :) 17:47:18 * sgallagh looks forward to quintuple-o. It's the next logical step, right? 17:47:20 <samkottler> rbergeron: SCORN 17:47:30 <rbergeron> okay, i think i get the picture 17:47:32 <rbergeron> sorry to be all questiony 17:47:44 <sgallagh> Questions now are more useful than questions in six months. 17:47:45 * mattdm thinks questiony is very helpful 17:48:37 <mattdm> here's an idea: what if we make server-in-the-sky one of the fedora cloud spins? 17:48:59 <mattdm> right now, we (tentatively) have a generic base, docker, and big data 17:49:00 * rbergeron was going to bring up load balancing but i think we can skip-it 17:49:08 <rbergeron> hmm 17:49:23 <samkottler> but what do you run on the server in the sky? 17:49:28 <mattdm> we could also have one that's basically got the server role-enablement stuff in place. 17:49:30 <samkottler> is it a db server or a IPA server or what 17:49:37 <sgallagh> mattdm: We were probably going to request help implementing this. It's one of our preferred delivery mechanisms. 17:49:52 <sgallagh> samkottler: "Yes" 17:50:12 <number80> how server and server-in-the-sky roles will be different ? 17:50:13 <mattdm> samkottler it's still also a base, but a base tailored for running the Fedora Server roles. 17:50:13 <samkottler> I guess the other issue is that one of the things we might have is a custom kernel build so it might just be bloated 17:50:56 * samkottler will have to think more about what it'd actually look like 17:51:11 <number80> samkottler: didn't the kernel team said that maintaining multiples kernels would be a PITA for them ? 17:51:32 <samkottler> in the meantime we can force people to to ephemeralize data by having jwb remove fsync from our kernel build 17:52:04 <jwb> done 17:52:19 <sgallagh> number80: Yes, they did. I think they were okay with breaking up the module subpackages, but not actual custom kernels. jwb? 17:52:36 <jwb> yeah. i'm already working on splitting up the packaging 17:52:42 <jwb> i have kernel-core and kernel-drivers 17:52:57 <jwb> kernel-core is what you guys keep saying should be the small thing, without actually telling me what you need in it. 17:53:13 <jwb> so right now, it literally just has the contents the kernel RPM puts in /boot. 17:53:21 <jwb> which... won't really work for anyone 17:53:28 <jwb> so. discuss. then inform. 17:53:53 <samkottler> we should probably include a general list of kernel requirements in the PRD 17:54:00 <jwb> \o/ 17:54:26 <samkottler> I think most of the requirements will be 'rip out this giant pile of drivers' 17:54:32 <jwb> (small caveat: it's not actually working perfectly yet, but i am workign on it at least) 17:54:37 <samkottler> so core won't be affected 17:54:43 * number80 gotta go or he'll be ear-raped by the office alarm 17:54:46 <rbergeron> should those kernel requirements inc. networking/ovs-type stuff? 17:54:49 <mattdm> jwb I can help make that more specific. Is there a bug or other place to help track what should actually be in there? 17:54:56 * rbergeron doesn't know that she's seeen networky-stuff anywhere really 17:55:16 <samkottler> rbergeron: I think ovs is in the server realm? 17:56:00 <jwb> mattdm, no bug. we could create one, or just use the kernel list. i have a new copr project i'm going to use to get people to test builds. 17:56:12 <jwb> rbergeron, ovs? 17:56:18 <jwb> oh, open-vswitch? 17:56:18 <samkottler> jwb: openvswitch 17:56:38 <jwb> yeah, we build that. i figured that and the virtio stuff would be good things to have in -core, but beyond that... 17:57:08 <jwb> and if this grows beyond "core", we can call it "base" instead 17:57:25 <mattdm> jwb hah 17:57:32 <rbergeron> samkottler: i do'nt know what's actually needed to be enabled where, but ... i'm pretty sure you would use it to manage gusests / connect them to each other in various ways? 17:58:04 <jwb> mattdm, i wasn't intending a dig. but it would be hard to say e.g. ovs is really "core" functionality 17:59:07 <jwb> and if you get to "do we want a firewall?" then you just grabbed a ton of netfilter drivers, etc 17:59:19 <jwb> which is why i would like you to tell me what you want :) 17:59:35 <jwb> because if it winds up being most of what we already have... then the exercise is rather pointless 17:59:39 <rbergeron> samkottler: http://www.itworld.com/virtualization/335244/rhev-upgrade-saga-rhel-kvm-and-open-vswitch 17:59:40 <samkottler> mattdm: I can work with you on kernel requirements 18:00:00 <mattdm> sounds good. 18:00:37 <rbergeron> anyway: i don't know my head from my ass on this but if it hasn't been thought about at all it might be worth thinking about . or consulting with someone 18:00:57 <rbergeron> who is more in-depth in ovs/neutron/open daylight land 18:01:04 <rbergeron> (mestery, cdub, etc) 18:01:53 * rbergeron shuts up 18:02:05 <mattdm> e.g. also not me. :) 18:02:17 <jwb> you cloud people have names that are amazing at not describing wtf they do 18:02:20 <mattdm> oh look. fesco time! i will keep this window open 18:02:24 * samkottler doesn't know enough about SDN to actually make decisions 18:02:27 <mattdm> jwb openstack is the WORST 18:02:36 <mattdm> it's got some sort of horrible name virus 18:02:52 <rbergeron> lol 18:03:01 <samkottler> jwb: openvswitch is the most descriptive 18:03:04 <samkottler> and it's still crap 18:03:09 <jwb> samkottler, was just going to say that 18:03:21 <jwb> need magic cloud decoder ring 18:03:40 <jwb> anyway, i'm awaiting further direction/discussion 18:03:49 <jwb> and i'd be happy to start spitting out copr builds 18:03:51 <samkottler> jwb: it's simple really...hook your heat up to your nova to route with your neutron to connect to cinder 18:04:02 <samkottler> welp, computers are bad 18:04:11 <jwb> at least they all have something to do with temperature! 18:04:30 * rbergeron notes that heat makes clouds rise (deploy, whatever), but i may have been involved with that naming 18:04:49 <rbergeron> ANYWAY 18:05:02 <samkottler> rbergeron: heat makes it rain 18:05:04 * rbergeron notes the time and things in the interest of decision making or otherwise 18:05:19 <samkottler> okay yeah let's keep it moving 18:05:36 <samkottler> any more PRD stuff that's pressing? 18:05:47 <samkottler> #action mattdm and samkottler to work on getting kernel requirements together for the PRD 18:07:17 <samkottler> bueller? 18:08:03 <samkottler> #topic open floor 18:08:24 <jzb> Nothing here. 18:08:28 <samkottler> so with the centos news and such, there is going to be a cloud SIG for centos 18:08:37 <samkottler> do we want to have some representation with them? 18:08:45 <jzb> samkottler: yes, I think we do. 18:08:57 <samkottler> jzb: twas kind of a loaded question 18:09:15 <samkottler> I've seen the idea of a shared cloud SIG between fedora and centos 18:09:18 <samkottler> what do people think of that? 18:10:01 <jzb> samkottler: would the scope be similar? 18:10:05 <rbergeron> that sounds epic. 18:10:07 <rbergeron> oh, sorry 18:10:09 <rbergeron> LOL 18:10:25 <samkottler> rbergeron++ 18:10:31 <samkottler> jzb: yeah I believe so 18:10:32 <jzb> rbergeron: I see what you did there. 18:10:39 <samkottler> centos might have some good guidance for us 18:10:45 <samkottler> they already build lots of divergent kernels and stuff 18:10:55 <jzb> true true 18:11:23 <jzb> samkottler: what do we need to do to make that happen? 18:11:37 <jwb> samkottler, actually, not lots 18:11:43 <jwb> i've been poking at them 18:11:46 <samkottler> jzb: I guess the big thing is just for people to be looking for convos on centos-devel 18:11:51 <samkottler> and make sure you're subscribed 18:12:15 <jzb> OK 18:12:28 <jwb> at least in my initial conversations, most of their kernels are still based on RHEL with the xen one being the only one i've found that actually diverged at a base kernel level (3.10 iirc) 18:12:36 <jwb> and their reasons were decent 18:12:41 * jwb shuts up 18:13:09 <samkottler> jwb: they have someone from citrix who manages the 3.10 builds? 18:13:17 <samkottler> the core team doesn't do it 18:13:34 <jwb> samkottler, yep 18:13:57 <samkottler> gotcha 18:14:02 <samkottler> well that's all I've got for the open floor 18:14:14 <samkottler> more PRD work to be done, but we're getting closer 18:14:27 <samkottler> jzb: rbergeron: mattdm: number80: geppetto: anything else? 18:14:38 <geppetto> nope 18:14:57 <jzb> samkottler: nope 18:15:09 <samkottler> #endmeeting ========================================== #fedora-meeting-1: cloud WG weekly meeting ========================================== Meeting started by samkottler at 17:01:57 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeting-1.2014-01-15-17.01.log.html . Meeting summary --------------- * rollcall (samkottler, 17:03:30) * PRD update and pending issues (samkottler, 17:07:14) * ACTION: mattdm and samkottler to work on getting kernel requirements together for the PRD (samkottler, 18:05:47) * open floor (samkottler, 18:08:03) Meeting ended at 18:15:09 UTC. Action Items ------------ * mattdm and samkottler to work on getting kernel requirements together for the PRD Action Items, by person ----------------------- * mattdm * mattdm and samkottler to work on getting kernel requirements together for the PRD * samkottler * mattdm and samkottler to work on getting kernel requirements together for the PRD * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * samkottler (89) * sgallagh (59) * rbergeron (48) * mattdm (44) * jzb (35) * jwb (30) * number80 (15) * zodbot (13) * geppetto (6) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
