Summary of yesterday's (1/15/2014) cloud WG meeting

[Sam Kottler]

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-meeti...
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeti...
 
Log (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-15/fedora-meeti...

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(a)gmail.com, 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(a)redhat.com&gt;
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(a)zonker.net&gt;
17:04:30 <zodbot> mattdm: User: mattdm, Name: Matthew Miller, email:
mattdm(a)mattdm.org, 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(a)redhat.com&gt;
17:06:19 <geppetto> .hellomynameis james
17:06:21 <zodbot> geppetto: james 'James Antill'
<james.antill(a)redhat.com&gt;
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_D...
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-a...
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-meeti...
.



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