cloud-sig
LOGS
21:00:25 <gregdek> #startmeeting Fedora Cloud SIG (2010-02-18)
21:00:26 <zodbot> Meeting started Thu Feb 18 21:00:25 2010 UTC.  The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:36 <gregdek> #meetingname cloud-sig
21:00:37 <zodbot> The meeting name has been set to 'cloud-sig'
21:00:56 <gregdek> Any objection to starting with our TODO list?
21:01:03 <gholms> Care to link to it?
21:01:14 <gregdek> https://fedoraproject.org/wiki/Features/FedoraOnEC2#Open_Action_Items
21:01:31 <gregdek> Note: this is the TODO list for Fedora on EC2, specifically.
21:01:38 <gholms> worksforme
21:01:43 <gholms> Oxf13: Are you here?
21:01:43 <gregdek> If no one objects, I'll start from the top and work my way down.
21:02:23 <gregdek> #topic first pass base ks with min packageset
21:02:30 <gregdek> huff: ping
21:02:40 <huff> gregdek: hi
21:02:49 <gregdek> Howdy.  :)  Any info on $topic?
21:03:00 <huff> so I posted the first pass ks to the list
21:03:05 <huff> did not get much feed back
21:03:21 * gregdek nods.
21:03:27 <mmcgrath> I don't remember seeing it
21:03:28 <gholms> Why use rc.local instead of a different init script?
21:03:38 <huff> :This ks file writes a custom fstab compatible w/ the ec2 infrastructure,
21:03:38 <huff> adds the ssh key stuff to rc.local, and enables sshd for remote long in.
21:03:38 <huff> It also creates an initrd image and moves it plus the vmlinuz image
21:03:38 <huff> outside of the images to be bundled and uploaded separately after image
21:03:39 <huff> creation.
21:03:45 * gregdek looks in the archives...
21:03:49 <mmcgrath> ahh, nm.  I found it.
21:03:52 <huff> gregdek: b/c thats what we have now
21:04:00 <huff> http://github.com/huff/kickstart-stuff/blob/master/fedora-ec2-min.ks
21:04:19 <gregdek> http://lists.fedoraproject.org/pipermail/cloud/2010-February/000078.html
21:04:48 <huff> or gholms thats what I had
21:05:14 <gregdek> Yeah, the email also includes workflow.
21:05:29 <gregdek> So now, what we need to do is point people to this workflow and say "worksforyou?"
21:05:41 <huff> yea was an idea of how it could work
21:05:41 <gregdek> Of course, we'll need an AKI to do that.  :)
21:05:58 <gregdek> We were working this in parallel.  So we'll mark this "done"
21:06:06 <gregdek> And move on.  Thanks huff, well done.
21:06:14 * gholms still has a question
21:06:18 <gregdek> Shoot.
21:06:24 <huff> any objections to building the initrd image inthe ks file
21:06:29 <gholms> Why rc.local and not a script in /etc/rc.d/init.d?
21:06:32 <huff> i thought it was a pretty good soultion
21:06:56 <huff> gholms: b/c i did nothave time to write one
21:07:01 <huff> and the script works
21:07:04 <jeremy> huff: why not just have it be built by the kernel %post instead?
21:07:06 <jforbes> huff: you can build it, but that isn't what will be used
21:07:22 <huff> jforbes: why
21:08:34 <jforbes> huff: because the kernels need to be up and validated without worrying about image creation. Meaning we might use that to create the ARI, but people will be building images using that ks which will not be pushing a new ARI
21:08:59 <gregdek> aiui, this ks is supposed to be a place to start for spinning "standard" AMIs as part of the release process.
21:09:09 <gregdek> Is it not suitable for that?
21:09:37 <huff> right we i thought we would build a  "standard" AMI AKI and ARI all at once
21:09:51 <huff> we need them to match
21:09:51 <gregdek> Yeah, I kinda thought that too.
21:09:55 <huff> well the ami and aki
21:09:58 <gregdek> Is that wrong?
21:10:22 <jforbes> The KS is suitable, just an unnecessary step for every image generation, since the ARI is not a part of the image, just referenced in the AMI definition
21:10:39 <jeremy> jforbes: I'm actually pretty concerned about people building new AMIs which end up using a newer kernel for the AMI and then modules not matching the available kernel.  but there's nothing we can really do about that I guess given the constraints amazon sets and we can't change :/
21:11:04 <huff> but we are talking about our offical fedora images
21:11:05 <gholms> "Remove your old kernel RPMs at your own peril"
21:11:08 <huff> not thrd party images
21:11:19 <gregdek> jeremy: we can't control the AMIs that others build, ever.  But we *can* control the AMIs *we* build, and we can get a Gold Star that says "these are kid tested and mother approved."
21:11:23 <jforbes> jeremy: Yeah, since they require that an external kernel is booted, we are stuck with that possibility
21:11:56 <jeremy> gregdek: oh, definitely.  and I think we should make sure our ami build process also does everything we can of building the aki/ari
21:12:02 <jeremy> if nothing else, it helps people that use eucalyptus
21:12:03 <gholms> The danger I can see is if someone has an image running long enough that the running kernel's modules are evicted during a yum update things will start going haywire.
21:12:14 <jeremy> and maybe it also can be a stick to beat amazon with
21:12:22 <jeremy> gholms: yum won't remove teh modules for the running kernel
21:12:24 <gregdek> The purpose of *this* ks was to give us a starting place towards building the first "official AMI".  Is this "good enough" for now?
21:12:27 <jeremy> gholms: wrote that code a long time ago :-P
21:12:47 <gholms> jeremy: Even if the running kernel came from somewhere else?
21:13:08 <jeremy> gholms: the modules are still from an rpm.  and then it uses some crazy matching based on uname()
21:13:46 <gholms> Sounds good to me, then.
21:13:46 <jforbes> gregdek: sure, the only thing I was saying, was that there is an extra step there which will not be needed most of the time, but it doesnt hurt really
21:14:00 <gregdek> OK.  We can ferret that out later if need be.
21:14:08 <gregdek> Ready to move on to kernel questions?
21:14:28 <jforbes> Sure, though nothing to report there
21:14:56 <jforbes> We haven't released the 2.6.32 update, and I don't know if we are any closer or not.  People seem bodhi happy with it, so maybe it will ship
21:15:02 <gregdek> #topic f13 kernel for ec2
21:15:28 <gregdek> Actually, I guess we're talking the f12 kernel for ec2, aren't we?
21:15:32 <gregdek> The update kernel, that is.
21:15:50 <jforbes> gregdek: yeah
21:15:59 <gregdek> So still stuck in bodhi.
21:16:08 <jforbes> gregdek: well, yes/no
21:16:27 <jforbes> gregdek: there have been several kernel builds with changes, but none that have been pushed through
21:16:39 <gregdek> When you say "people seem bodhi happy," then, what do you mean?
21:16:51 <gregdek> Has the latest build been sitting for a while and people have voted it up?
21:16:56 <gregdek> Or is there still churn?
21:17:14 <jforbes> it was noted today that a kernel is sitting in bodhi with 2 karma, and it hasn't even made it to updates-testing yet
21:17:35 <gregdek> Hm!  Who do we poke about that?
21:17:38 <jforbes> gregdek: yeah, there has been churn, but any of them could be considered good enough
21:17:53 <gregdek> Is this Oxf13's call, or what?
21:17:58 <jforbes> gregdek: no one to poke, people have to test kernels, and they do... Unfortunately they find issues
21:18:09 <Oxf13> sorry, I'm here.
21:18:21 <ewan> Do we know for sure that the kernels in bodhi are definitely Xen/EC2 capable?
21:18:24 <gregdek> So we're just waiting for *any* kernel to make it thru updates-testing.
21:18:25 <Oxf13> we're going to try to work in another push today, but we've had some bodhi issues
21:18:26 <jforbes> gregdek: so we have a few regressions with .32, and a large number of issues fixed.
21:18:33 <Oxf13> which is outside the scope of the kernle issues
21:18:40 <jforbes> ewan: yes
21:18:40 <Oxf13> but fingers are crossed for this kernel build.
21:18:58 <gregdek> ok.  we'll keep checking in.  :)
21:19:03 <gregdek> Anything else?
21:19:17 <jforbes> nope
21:19:20 <ewan> Is it worth getting one of the bodhi kernels up on EC2 and testing it there then? They are supposed to be being tested after all.
21:19:21 <gregdek> #info no change on f12 kernel status
21:19:34 <huff> ewan: ++
21:19:39 <gregdek> #info dhuff ks is "good enough for now", move that item to "complete"
21:19:53 <jforbes> ewan: we are testing essentially the same thing, on RHEL hosts here
21:19:57 <huff> story of my life
21:20:01 <gregdek> Hee hee.
21:20:51 <gregdek> If jforbes is confident that the kernel will run on EC2 xen hosts, I see no reason to rush a bodhi-based build on to EC2, I guess.
21:20:59 <gregdek> jforbes, you're quite sure?  :)
21:21:24 <jforbes> gregdek: yeah, we had a rather extensive call with them, we know what they are running for hosts
21:21:29 <gregdek> Great.
21:21:38 <gregdek> And if you're wrong, we reserve the right to make fun of you.
21:21:46 <gregdek> (But we do that anyway, I guess.)
21:21:50 <jforbes> But of course :)
21:22:00 <gregdek> Moving on:
21:22:02 <ewan> Makes sense to me.
21:22:06 <gregdek> #topic jforbes will document kernel/initramfs upload process
21:22:12 <gregdek> jforbes?
21:22:19 * gregdek wanders afk for a sec, brb
21:23:05 <jforbes> gregdek: right, documentation is being updated as the first real kernel is pushed
21:23:54 <gregdek> So this waits also.
21:24:16 <gregdek> #info kernel/initramfs upload process will be done when first real kernel is pushed
21:24:18 <jforbes> I have documentation from the last time I did it, but we need to make sure that it is accurate/relevant for fedora, so the doc part is easy
21:24:28 <gregdek> Good enough.
21:24:32 <gregdek> I guess we can move on, then.
21:24:49 <gregdek> #topic jforbes will share upload credentials with Fedora kernel developers
21:25:06 <gregdek> Who needs this, actually?  Did they get it?
21:25:28 <gregdek> This isn't critical until we've actually got a working build process, I suppose, hm?
21:25:31 <gholms> Just the kernel package maintainers?
21:25:31 <jforbes> gregdek: davej, kylem, and cebbert, and they will get it with the documentation
21:25:58 <gregdek> gholms, I've got to think we want to limit this, since it will define "authoritative" kernels.
21:26:00 <jforbes> They are aware that it will be coming to them
21:26:16 <gregdek> We'll have a testing account that will be more widely available, i think.
21:26:21 <jforbes> Right, not everyone with commit access to the kernel, just certain people
21:26:42 <gregdek> I mean... we definitely have two accounts.  We just have to figure out at some point exactly what each one is used for.
21:27:15 <gregdek> #info upload credentials will be ready when upload documentation is ready
21:27:35 <gregdek> Anything to add there?
21:28:02 <gregdek> Bueller?
21:28:04 <gregdek> No?
21:28:07 <gregdek> OK, moving on:
21:28:47 <gregdek> #topic gregdek will ask amazon to host srpms / update servers / s3 for mirror manager
21:29:20 <gregdek> This all falls under the broader "working to get as much stuff as possible from Amazon for free".  :)
21:29:36 <gregdek> Which is still waiting on a series of meeting with Nathan Thomas, so nothing to update there for now.
21:29:54 <gholms> Nathan Thomas?
21:30:01 <gregdek> Our guy at Amazon.
21:30:04 <gholms> Ah
21:30:15 <gregdek> Formerly of RH and rPath, so we know him and can work with him.
21:30:42 <gregdek> #info amazon hosting of srpms / update servers still waiting on meetings with Amazon folks
21:30:47 <huff> gregdek: there are some negiotions on the rhel side for sothing simular i think we may be able to jump on that
21:30:56 <gregdek> huff, is ferris working on that?
21:30:59 <huff> yea
21:31:03 <gregdek> I'll ping him, then.
21:31:30 <gregdek> Any questions about any of that?
21:31:48 <gregdek> Seems like a no.
21:31:50 <gregdek> Moving on:
21:31:53 <gholms> What's next?
21:32:02 <gregdek> #topic Get euca2ools approved in Fedora
21:32:08 <gholms> Ooh, that's me!
21:32:10 <gregdek> gholms?
21:32:11 <gregdek> :)
21:32:24 <gholms> euca2ools 1.1 is in updates-testing now.
21:32:37 <gregdek> woo!
21:32:50 <gregdek> And I just blogged for folks to go give it karma, so maybe that'll help a bit.
21:32:50 <gholms> I pushed 1.2 ten minutes ago, so look for it next time repos are composed.
21:33:28 <gholms> https://admin.fedoraproject.org/updates/euca2ools-1.2-1.fc12
21:33:40 <gholms> Also https://admin.fedoraproject.org/updates/euca2ools-1.2-1.fc13
21:34:18 <gregdek> Anything we can do to drive people?
21:34:45 <gholms> Push people to use EC2 and Eycalyptus?
21:34:53 <gholms> *Eucalyptus
21:35:03 <gregdek> Well, push them to test euca2ools, anyway.  :)
21:35:31 <gholms> Oh, that's easy.  Upstream doesn't have Fedora RPMs for it so there really isn't a choice.  :)
21:35:35 <gregdek> I'm likely to start using euca2ools myself.
21:35:43 <gregdek> LOL
21:36:00 <gregdek> All right.  We'll just advertise them and hopefully that'll get the packages the needed karma.
21:36:07 <gholms> I install ec2-api-tools alongside euca2ools and use euca-* whenever I can.
21:36:18 <gregdek> Good tip.
21:36:51 <gregdek> Do you have good / recent docs about what euca-* don't work at this point?
21:37:37 <gholms> Things that are specific to EC2, like spot instances and pay-for AMIs, don't work.
21:37:57 <gholms> The bug with euca-register is fixed with the version of python-boto from updates-testing.
21:38:19 <gregdek> Oh, so this is python based rather than java based, like ec2-api-tools?  Win!
21:38:43 * gregdek still hasn't gotten upgraded from F11, lolfail
21:38:50 <gregdek> I can't even test until I upgrade.  Moron.
21:39:08 <gregdek> Anyway, I guess no updates there.
21:39:25 <gholms> Unless you want to use spot instances on EC2 you should try using euca2ools to do your instance management.
21:39:44 <gregdek> gholms, I will once I get upgraded to F12.  Hopefully this weekend.
21:39:48 <gholms> :D
21:39:59 <gregdek> All right, that's our opens.
21:40:05 <gholms> Has anyone else here tried euca2ools out yet?
21:40:10 <gregdek> Anyone?
21:40:13 <ewan> I have a bit.
21:40:21 <gregdek> IS IT NOT AWESUM??
21:40:26 <ewan> Against EC2 and Eucalyptus.
21:40:31 * gholms smacks gregdek with a large trout
21:40:36 <ewan> Well; it does what it says it does :-)
21:40:45 <gregdek> ewan, have you tried the actual F12-testing packages?
21:40:56 <ewan> I haven't tested all (or even most) of the tools as yet though.
21:40:57 <gholms> There are no other packages, at least on Fedora.
21:41:23 <ewan> gregdek: Yes. And I've just grabbed that latest one from Koji, so I'll give that a go too.
21:41:33 <gholms> Things looking okay so far, at least?
21:41:36 <gregdek> ewan, rock on.  Please karma if appropriate.  :)
21:41:53 <gholms> Please karma if not appropriate.  We need bug reports for problems.
21:42:08 <ewan> Yup. Haven't tried registering a new image (on account of the know python-boto prob) but starting, stopping, new keypairs....
21:42:13 <gregdek> Oh, true.  Karma + or - either way.
21:42:20 <ewan> Yup. Will do.
21:42:31 <gholms> ewan: Grab python-boto from updates-testing and that should work.
21:42:31 <gregdek> gholms, anything else for euca2ools?
21:42:43 <gholms> That's it for me.  Anyone else have anything for that?
21:43:11 <gregdek> #info euca2ools-1.2 going into bodhi RSN, ewan will test, gregdek will test
21:43:34 <gholms> I'm using it for some research work, so I'll obviously be testing it too.  :)
21:43:59 <gregdek> #action ewan, gholms, gregdek will test euca2ools-1.2 from bodhi
21:44:12 <gholms> What's next?
21:44:13 <gregdek> I guess that's it.  Are we ready to move to open floor?
21:44:23 <gholms> Anything IBM-related?
21:44:28 <gregdek> Oh, right.
21:44:34 <gregdek> That didn't get on our list.
21:44:42 <gregdek> #topic IBM cloud stuff
21:45:09 <gregdek> I'm not actually sure what's actionable here, besides folks "playing with stuff".
21:45:13 <gregdek> I guess here's the question:
21:45:44 <gregdek> Do we want to take the IBM "Fedora cloud images" on while also working on the EC2 images?
21:46:10 <gholms> Are the images similar?
21:47:17 <gregdek> I don't know.
21:47:33 <huff> their kvm based instead of xen
21:47:37 <huff> i dont knwo much more
21:47:55 <gregdek> Basically, someone needs to say "I'm messing with the IBM stuff and I'm interested in driving Fedora to GREAT SUCCESS!"  Or... um... put it on the back burner.
21:48:02 <gregdek> My $0.02.
21:48:34 <gholms> Anyone here interested in finding out more info on the IBM cloud?
21:48:36 <gregdek> I mean, let's face it: bazillions of people are using EC2 right now, and IBM's stuff is a newly announced beta.
21:48:42 <gregdek> So EC2 is clearly more pressing.
21:49:06 <gholms> EC2 is also more pressing so we can nuke all the FC4/6/8 images.  :)
21:49:08 <gregdek> That said, if someone is Very Interested...
21:49:17 <gregdek> ...but seems like... Not.
21:49:17 <smooge> didnt SGI also announce a 'cloud' this week..
21:49:26 <huff> and once we have a standard way of building images they should be "simular"
21:49:29 <gregdek> LOL
21:49:34 <gregdek> The SGI cloud?  srsly?
21:49:43 <smooge> yeah.. I think so.
21:49:55 <smooge> it sounds like cloud has reached that level of ubiquity
21:50:00 <ewan> They did, but it didn't sound much like a cloud.
21:50:04 <smooge> its like Staples announcing they do Linux support now
21:50:06 <gregdek> All right, since no one seems to be rushing forward to take IBM... I think it's time for Open Floor time.
21:50:16 <gholms> I propose we wait for more info to make it to the list; there clearly isn't enough interest or even info about the IBM cloud to do anything yet.
21:50:18 <smooge> what does taking IBM mean.
21:50:30 <smooge> that can be open floor
21:50:30 <jforbes> Well, isn't SGI Rackable now? That isn't surprising
21:50:33 <gregdek> gholms, I agree.
21:50:41 <gregdek> #topic Open Floor
21:50:53 <gregdek> Who has questions?
21:51:01 <gregdek> Or topics for the bully pulpit?
21:51:04 <ewan> Couple of things:
21:51:28 <ewan> Ubuntu seem to have niceish EC2/Eucalyptus init scripts,
21:51:37 <mmcgrath> I don't have anything but I did want to mention I did this ticket for FESCo the other day:
21:51:49 <ewan> we should see if they've got anything we could derive inspiration from/lift wholesale.
21:51:52 <mmcgrath> https://fedorahosted.org/fedora-engineering-services/ticket/1
21:52:51 * huff has to run ill check the mailing list later or shoot me an email if you need anythign form me
21:53:24 <ewan> Other thing's a bit of an odd one:
21:53:38 <gholms> ewan: What sorts of init scripts?
21:53:38 <gregdek> mmcgrath, nice.
21:54:01 <gholms> mmcgrath: Reminds me of all the VPSs that way they run on "CentOS."
21:54:05 <gholms> *say they
21:54:14 <mmcgrath> :)
21:54:52 <ewan> gholms: Importing SSH keys etc. I haven't examined them too closely, but they're not short, so it might be worth seeing what they're up to.
21:55:20 <gholms> ewan: Are you okay with taking that on as an action item?
21:55:56 <ewan> gholms: Yes, I can have a look at them certainly. I'll try to report some impressions back to the list.
21:56:08 <gholms> #action ewan to look at Ubuntu's EC2 init scripts
21:56:16 <gregdek> It might also be useful to look at what Turnkey Linux is doing, too.
21:56:39 <gregdek> Since they've got, afaict, a whole *library* of images.
21:56:59 <gregdek> All of which are 100% open source, although whether that means they're easy to find, I couldn't say.
21:57:12 <gholms> ewan: You had another thing to bring up?
21:57:16 <gregdek> http://www.turnkeylinux.org/docs/tklpatch
21:57:32 <ewan> Other (oddish) thing: Amazon's EC2 control panel offers 'Fedora' as a platform, but most of the things so listed wouldn't meet the trademark guidelines if you burnt them to a CD. Do we want to do anything about that use of the name and logo?
21:58:27 <gholms> Sounds like a Board question.
21:59:32 <gregdek> Hm.
21:59:41 <gregdek> Well...
21:59:44 <ewan> It's definitely hmm-worthy.
21:59:54 <gregdek> ...that's definitely the backdrop of basically everything we're doing.
22:00:01 <ewan> I don't have a strong opinon on this one, but it struck me as worth thinking about.
22:00:09 <gregdek> Well, I've got some opinions.  :)
22:00:17 <gholms> When's the next Board meeting?  Should someone bring it up then and see what everyone thinks?
22:00:20 <gregdek> This will *definitely* be an issue.
22:00:32 <gregdek> Well, Paul already knows about it, that's certain.
22:00:59 <gholms> I'd be hesitant to do anything until we get an official image up.
22:01:00 <gregdek> I myself have deferred talking much about it until we have a good solution for them, since I think it's mostly a question of being able to comply technically.
22:01:05 <gregdek> gholms, exactly so.
22:01:08 <gregdek> Which means:
22:01:15 <gregdek> 1. Get our shit together;
22:01:27 <gregdek> 2. Work to get Amazon in compliance.
22:02:00 <ewan> worksforme
22:02:02 <gholms> +1
22:02:09 <gregdek> "And that's all I have to say about that."
22:02:35 <gholms> Anything else?
22:02:54 <gregdek> Not from me.
22:03:37 <gholms> Dinner awaits!
22:04:16 <gregdek> #endmeeting