Cloud image/ kernel/OVS followup
by Robyn Bergeron
----- Forwarded Message -----
> From: "Josh Boyer" <jwboyer(a)fedoraproject.org>
> To: "Fedora community advisory board" <advisory-board(a)lists.fedoraproject.org>
> Sent: Wednesday, January 22, 2014 5:03:09 AM
> Subject: Re: Proposal: Revision of policy surrounding 3rd party and non-free software
>
> On Wed, Jan 22, 2014 at 5:15 AM, Christian Schaller <cschalle(a)redhat.com>
> wrote:
> > The thinking is simply that we can solve this and we can solve it in a way
> > that isn't detrimental to the user experience of Fedora users.
> >
> > It is already likely there will be some changes in the Fedora kernel policy
> > due to the Cloud WG wanting a different kernel, so as part of the process
> > going forward there will be negotiations between the different WGs and
> > with the Fedora kernel team to figure out what the different needs are,
> > what is viable within the constraints of the resources we have, what are
> > the possibilities and challenges each available solution bring.
>
> Just a note, the kernel efforts around the Cloud product thus far have
> mostly be in terms of packaging, not a _different_ kernel. Mostly
> splitting it up into kernel-core and kernel-drivers, etc. That
> doesn't change policy. It has also been discussed on the kernel and
> cloud lists, as well as in the cloud meetings, just so that people
> don't think we're off making changes without discussion.
Along these lines (and a GIANT ADVERTISEMENT to those of you who don't follow the advisory-board list that that is srs discussion going on, heh) -
I know we talked last week about the inclusion of OVS-related kernel things in the Cloud image and it was debated whether or not it was needed. (This was mostly me pondering aloud and not being super-sure, and less of a debate, I suppose. :D)
My investigation into this - which admittedly consisted of mentioning it to my significant other (who is on this list, and does OpenStack things) over dinner a few nights ago - resulted in the following:
* You guys were right, it's really only needed on the host
* Unless you are doing something along the lines of Triple-O (OpenStack-on-OpenStack, https://wiki.openstack.org/wiki/TripleO) - where you have OpenStack running in the traditional way, and then one or more OpenStack(s) running on *top* of that infrastructure, in which case you'd be doing nested virtualization, and then the additional OpenStacks running on top of the primary OpenStack would need OVS in the kernel.
So I'm not really sure how in the heck we'd want to handle that, or what we'd recommend for those "secondary" OpenStacks - the Cloud or Server product - I am sure some folks on this list have opinions being more in tune with that particular OpenStack project than I am.
The third "investigatory point" - which I'm sure most of you guys know anyway - is that including it in the kernel is not really something that is significant in terms of size. But I know we are trying to get down to as small of a footprint as possible. I also don't know if it presents an additional point of failure (could OVS go haywire and break the kernel if it's not being utilized, but just present? more technical things I am not sure about) - but if it does I am sure that might be something to consider.
mestery, cdub, anyone else... if there are other thoughts (or, uh, corrections) you folks have - they are (as always) welcomed :D
-robyn
ps. If you guys already figured all of this out and I'm just blind... ignore me :D
>
> josh
> _______________________________________________
> advisory-board mailing list
> advisory-board(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board
10 years, 3 months
prd is approved by fesco. now: next deliverable!
by Matthew Miller
The PRD is approved. Go, us!
Our next deliverable falls out of our PRD requirements, plus whatever we
forgot to list:
The second deliverable should be a list of necessary changes from
existing Fedora procedures needed to release the product. This should be
ordered to show what things depend on other changes and at which point
the changes will mean that we can no longer produce the current type of
Fedora. This will allow us to identify the resources needed by what teams
in order to implement the plan and at what point we may need to have a
longer than normal release cycle to do tooling work.
Because FESCo want to work on figuring out the F21 schedule kinda soon, this
will be due on Feb 17th, but let's not wait for the last minute.
I made https://fedoraproject.org/wiki/Cloud_NextChange so we can get
started. :)
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
10 years, 3 months
Cloud SIG trac
by Matthew Miller
We made one, at https://fedorahosted.org/cloud/.
And, I just set it so that tickets will get CCd to this list.
Feel free to use this for anything Fedora-cloud-related which you think
might benefit from being tracked in some way. :)
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
10 years, 3 months
Reminder + agenda for tomorrow's (1/22/2014) cloud WG meeting
by Sam Kottler
Following is the list of topics that will be discussed in the cloud WG meeting Wednesday at 17:00 UTC in #fedora-meeting-1 on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2014-1-22 17:00 UTC'
= New business =
None right now.
= Followups =
* PRD recap, pending issues, and potentially initial assignment of work
* GCE image status update
* FOSDEM/cfgmgmtcamp/infrastructure.next meetup planning?
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/cloud, or bring it up at the end of the meeting during the open floor.
-Sam
10 years, 3 months
Intro and a question or two
by Michael Hall
Hi, I've been lurking here for a week or two and can see I've joined at an
exciting time.
I work in web development and sysadmin in Australia and am particularly
interested in Fedora as LXC host and guest for Nginx/NodeJS/PHP-FPM and
associated datastores.
ATM I'm playing with kernel recompiles and seeing just how much stuff I can
pull out without affecting a VM. Some stuff is obvious, other stuff totally
obscure. Any guidelines on this? The goal is a custom Google Cloud image.
Also, the Docker website says that docker-io is available for Fedora 20 but
I'm having trouble finding it. Clues?
Congrats to all involved in the PRD work to date. I'll consider putting my
hand up for things when I know the ecosystem better.
Mike
10 years, 3 months
Initial PRD vote
by Sam Kottler
Hi all,
As you probably know, we've been working on the product requirements document for the last few months, and particularly heavily over the last 2 or 3 weeks. It's not yet in a final state, but I'd like to gather initial +1/-1's from voting members of the working group since it's due today. You can view the document at http://cloudpad-samkottler.rhcloud.com/p/PRD.
So I'll kick this off: +1. :-)
-Sam
10 years, 3 months
prd status -- getting better, needs your help! (due monday!)
by Matthew Miller
Still working on this in the cloud etherpad -- coordinate in #fedora-cloud
on IRC (ping samkottler or mattdm if no one seems to be around).
The for of the document overall is in pretty good shape, but lots of
sections need expansion. I've tagged these with FIXME. The bad news is that
there's almost 100 of these. The good news is that none of it is really
complicated -- they just need fleshing out. I could really use all of your
help in doing so.
I'm going to be away-from-keyboard for a bit (family and non-work-life
beckons!), but will try to chip in over the weekend too. Let's get this
done!
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
10 years, 3 months
Summary of yesterday's (1/15/2014) cloud WG meeting
by 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>
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>
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>
17:06:19 <geppetto> .hellomynameis james
17:06:21 <zodbot> geppetto: james 'James Antill' <james.antill(a)redhat.com>
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
10 years, 3 months
prd final push
by Matthew Miller
Okay, let's get this done -- due date is Monday. The "features" section is
kind of in need of love. After that (and, hopefully, following from it) is
the requirements section. There's a preliminary bullet list of those
requirements at the top of the section, and those need to be made into the
right format.
--> to the regular #fedora-cloud channel on Freenode IRC for coordination.
Sam has been copying the wiki page to an etherpad for collaborative hacking
and then copying it back when done, so pop into the channel and see what the
state is.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
10 years, 3 months