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