21:00:29 <gregdek> #startmeeting
21:00:30 <zodbot> Meeting started Thu Mar 25 21:00:29 2010 UTC.  The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:37 <gregdek> Hello.  Thanks for coming.
21:00:46 <gregdek> #topic Roll Call
21:00:48 <gregdek> Roll call, pls?
21:00:54 * lutter here
21:01:04 * gholms is here
21:01:06 * jonmasters here
21:01:15 * huff here
21:01:22 * jforbes here
21:01:24 <smooge> is here
21:01:30 * smooge here
21:01:37 * mmcgrath here
21:01:38 * skvidal is just watching
21:01:42 <gregdek> #meetingtopic Fedora Cloud SIG meeting
21:02:02 <gregdek> Good enough.
21:02:12 <gregdek> huff, since you're in a hurry, want to lead off?
21:02:28 <huff> sure
21:02:37 <huff> what the Image will look like, and how it will be built ie:
21:02:38 <gregdek> #topic Image Building
21:02:43 <huff> Partitiing info
21:02:45 <huff> package set
21:03:00 <huff> default services
21:03:03 <huff> selinux?
21:03:04 <huff> Build plan
21:03:11 <huff> I proposed an initial ks, and people seem to comment on it, but i have not seen any updates or suggestions
21:03:15 <gregdek> I don't think we've settled on any of these things.
21:03:31 <gregdek> And because we haven't seen any updates or suggestions, your initial ks is where we'll start!  ;)
21:03:35 <huff> thats fine
21:03:46 <gregdek> Doesn't mean it's where we'll finish, of course.
21:03:46 <huff> i just wanted ppl to be aware that they need to be worked out
21:04:05 <gregdek> Yep.  Trouble is, I don't think we know what the implications are until we start testing.
21:04:13 <huff> works for me
21:04:17 <gregdek> My working assumption was that we'd use the Spins as a guide.
21:04:23 <gregdek> I don't know if that's valid or not.
21:04:28 <gholms> Doesn't EC2 have a preferred partitioning scheme?
21:04:29 <gregdek> And should probably be discussed... well, now.
21:04:31 <jonmasters> Is this e.g. an EC2 image?
21:04:31 * smooge goes to look at ks
21:04:36 <smooge> sorry I missed it
21:04:47 <jonmasters> Because I think they want a pre-built image, not something you ks each time
21:04:55 <gregdek> jonmasters, they do.
21:05:07 <jonmasters> gregdek: so is this just ks once to build it then?
21:05:19 <huff> gholms: will I have have recently discovered ec2 usually wants a single partitioned imagen
21:05:19 <gregdek> The question is, how do we build that image?  And how do we make it part of the Fedora release process to build a good set of "default" images?
21:05:20 <jforbes> in fact, they want an fs image, not really a disk image
21:05:34 <huff> however it can have a multi-partitioned image using device-mapping
21:05:47 <huff> and our tools spit out mulit-partitioned images
21:05:54 <gholms> jonmasters: Yep.  It's like generating the Live ISO.
21:05:55 <jonmasters> gregdek: I guess the closest analogy is a live image
21:05:58 <gregdek> Yep.
21:06:00 <jonmasters> right
21:06:01 <gregdek> Pretty much.
21:06:18 <jforbes> Not sure why we would parition at all for a non perisitent image
21:06:33 <jonmasters> but also not, because there's a lot you can take out. Is it planned to use the same F12 kernel or a rebuild for the (separate) EC2 kernel btw?
21:06:46 <jforbes> Hand a filesystem image with a common mount point (say /data) for users to mount their S3 storage
21:07:05 <jforbes> jonmasters: standard kernels
21:07:17 <bobmcw> ec2 should be getting the f12 kernel "soon"
21:07:18 <jforbes> Well, standard vmlinux images from kernel-debuginfo
21:07:20 <jonmasters> then I guess a standard ISO-like spin is good enough too
21:07:26 <gregdek> I think there's a ton of things we *could* do.  My question is, what's the sensible starting point for what we *will* do, and work forwards from?
21:07:35 <gregdek> Like, S3 linkage is clearly awesome.
21:07:39 <gregdek> Is that where we start?
21:07:46 * pbrobinson is here. sorry for being late
21:07:56 <gregdek> Hey probinson.  :)
21:08:06 <jforbes> gregdek: that seems the most simple.  single fs image, not even a disk image for / and a mount point for user S3 storage
21:08:08 <lutter> gregdek: are you assuming we have the whole image building / package set discussion figured out ?
21:08:43 <huff> jforbes: will appliance-tools builds a disk image with a partion table
21:08:48 * eric-smith is here
21:08:52 <gholms> gregdek: Do we still need to generate ARIs for updated kernels?
21:08:54 <gregdek> lutter, no.  I'm looking for a place to start for testing.  My guess is that we're gonna get it a bit wrong to start.
21:08:56 <huff> so in order to use that you have to tell ec2 about it
21:09:02 <eric-smith> To my knowledge, you can't mount S3. You'd mount EBS.
21:09:05 <gregdek> Clearly, we want to get it "least wrong".
21:09:09 <huff> or extract the / fs image
21:09:37 <jforbes> eric-smith: you can moutn S3, but they prefer EBS now I suppose
21:09:49 <bobmcw> I hope everyone's looked at the BoxGrinder stuff
21:09:51 <huff> b/c it cost more?
21:10:07 <gregdek> huff, b/c it's persistent.  :)
21:10:10 <bobmcw> we don't do EBS mounts (yet, planned), but we build quite a few appliances, including a meta-appliance, which can build more.
21:10:31 <gholms> huff: Cost is the same for users.  EBS costs them less because it's limited to the same aviilability zone as the EC2 instances.
21:10:36 <huff> so the problem Ihave seen with ebs is oyu need a image runing and mounted to upload an image
21:10:44 <gregdek> bobmcw, no one's looked at BoxGrinder yet I don't think, because it's largely been moot, since we've had no updated kernels in EC2.
21:10:48 <huff> where as with s3 you can upload directly
21:11:03 <jonmasters> you don't mount S3 as a normal filesystme though
21:11:10 <bobmcw> you seed an EBS from an S3 snapshot
21:11:18 <bobmcw> (or can)
21:11:21 <jonmasters> you can use the experimental-ish S3 FUSE stuff, or upload scripts
21:11:30 <bobmcw> so I imagine we can jam something up there out-of-band w/o a running instance
21:11:46 <bobmcw> or at least a 2gb sparse /home snapshot they can clone onto EBS at first boot
21:11:51 <jonmasters> but I wouldn't try to support S3 out of the box with FUSE because that's still quite young code, with three different implementations
21:12:08 <jonmasters> And each one figures out how to do directories (S3 doesn't do directories natively, only buckets)
21:12:30 <bobmcw> seems to be standardizing on that lately
21:12:31 <eric-smith> Just getting an image with no EBS or S3 support would be an awesome first step
21:12:35 <bobmcw> several clients I've tried treat'em alike
21:12:41 <bobmcw> s3fox, cyberduck (osx)
21:12:52 <lutter> isn't the simplest thing to test a recent Fedora image that you can successfully log in with ssh ? Do we have the path for that, including updates etc. defined ?
21:13:00 <gregdek> lutter, I agree.
21:13:02 <gregdek> In fact...
21:13:09 <gregdek> ...I'd love for that to be our first deliverable.
21:13:18 <huff> +1
21:13:20 <lutter> it feels like unless we have figured the above out ,including how that ties into releases etc. everything else is moot
21:13:21 <gregdek> (After getting the kernels squared away, of course.)
21:13:42 <lutter> yeah, kernels a re a prereq for that
21:13:44 <gregdek> lutter, I believe that exact thing was what huff's proposed ks was.
21:13:49 <gregdek> huff, right?
21:13:54 <huff> yep
21:13:59 <gregdek> So here's what I'd like to see.
21:14:01 * eric-smith has to leave. sorry, but thanks for the great work. I'm looking forward to helping
21:14:01 <gregdek> Tell me what you think.
21:14:07 <gregdek> Thanks eric-smith!
21:14:22 <gregdek> The second we get the go-ahead from jforbes that "kernel is live"...
21:14:51 <gregdek> ...I want huff to build an image with his ks and his tools, give us the AMI id, and say "this is how I made it."
21:14:59 <lutter> does anybody feel like they can write up the process for regular/recent Fedora images in EC2 ? And who's doing what (not necessarily people but releng/amazon/cloud sig) ?
21:15:00 <gregdek> And I would like bobmcw to do the same with boxGrinder.
21:15:09 <bobmcw> gregdek: sure thing,  ami-cfe000a6
21:15:12 <jforbes> gregdek: we can discuss that when we get to the kernel bit
21:15:17 <gregdek> Since these two folks have actually done it.  :)
21:15:18 <smooge> what is boxGrinder?
21:15:20 <bobmcw> that's f11 though, but we're just awaiting kernel to rebuild for f12
21:15:28 <lutter> bobmcw: what version of fedora is that ?
21:15:42 <bobmcw> smooge: http://jboss.org/stormgrind/projects/boxgrinder.html
21:15:43 <gregdek> bobmcw, and the instructions for how it was done.  :)
21:15:49 <bobmcw> lutter: I think it's F11 built on F11
21:15:55 <bobmcw> might be F12 built on F11
21:16:04 <bobmcw> F12 on F12 fails today, though
21:16:07 <huff> but with amazon provided kernels
21:16:10 <bobmcw> huff: right
21:16:17 <bobmcw> we're excitedly awaiting fedora kernels
21:16:24 <huff> :
21:16:26 <huff> )
21:16:27 * jonmasters feels building with ks on target might not be the best longer term strategy
21:16:30 <bobmcw> should improve our f12-on-f12 I think
21:16:36 <gregdek> jonmasters, you may well be right.
21:16:46 <bobmcw> that AMI is our meta-appliance, so you can boot and start playing with boxgrinder
21:16:48 <gregdek> In fact, I think you likely *are* right.
21:16:58 <jonmasters> gregdek: it's not reproducible
21:17:02 <bobmcw> http://jboss.org/stormgrind/projects/boxgrinder/build.html
21:17:23 <bobmcw> http://community.jboss.org/wiki/StormGrindBoxGrinderDocumentation
21:17:44 <bobmcw> repos: http://github.com/stormgrind/
21:17:52 <bobmcw> blog http://cloudpress.org/
21:18:12 <smooge> looking at the kickstart the only issues I have with partitioning is /tmp, /var/tmp for permissions but that is just me... sorry
21:18:20 <smooge> bobmcw, thanks
21:18:35 * gregdek waits a bit.
21:18:45 <gregdek> There's a million ways to build an EC2 image.
21:18:53 <bobmcw> easy to consume preso: http://stormgrindcloud.files.wordpress.com/2010/02/boxgrinder-opencloudforum.pdf
21:19:16 <huff> gregdek: I am fine with commiting to the above: building an image w/ my tools & write up the process I used
21:19:23 <gregdek> What's going to be the way that we build the *first and best default* for F12?
21:19:30 <gregdek> huff, thanks.  :)
21:20:09 <huff> in fact my account has that ability that jforbes is waiting on i can do it now
21:20:24 <gregdek> huff: using the F12 kernel?
21:20:27 <huff> well except the fact its five and have prior engaguments
21:20:36 <gregdek> huff, no worries.  Soon.  :)
21:20:36 <huff> gregdek: yea
21:20:41 <jforbes> F12 is of slightly less concern since it is a one off image... While we need to get it done soon, we really need to focus on how F13+ will be done
21:20:47 <bobmcw> within 10min of the f12 kernel, we can have an AMI up, if Marek's awake :)
21:20:48 <jforbes> huff: My waiting is ovr
21:20:55 <bobmcw> he's in poland, not awake now.
21:21:01 <huff> nice
21:21:06 <gregdek> LET US RACE TO THE LINE!
21:21:14 <gregdek> :)
21:21:21 <lutter> I feel an embarrassment of images coming
21:21:25 <gregdek> Good.  :)
21:21:34 <gregdek> So long as there's also:
21:21:35 <huff> lutter: what is taht
21:21:37 <huff> that
21:21:52 <gregdek> * An embarrassment of documentation on how they were built, and how to use them to build other images;
21:21:54 <lutter> huff: playing on 'embarrassment of riches' .. not very good pun, actually
21:22:32 <gregdek> * A proposed process to do it automagically as part of Fedora releng.
21:22:44 <gregdek> I believe that the first will help us get to the second.
21:22:56 <lutter> agreed
21:23:04 <gregdek> So then.
21:23:27 <gregdek> #action huff will create F12 image + documentation with his toolset and ks
21:23:40 <gregdek> #action bobmcw will create F12 image + documentation with boxgrinder
21:23:51 <gregdek> Yes?
21:24:00 <bobmcw> yah, at this point a JeOS/minimal
21:24:07 <gregdek> Perfect., I'd say.
21:24:12 <huff> works4me
21:24:13 <bobmcw> it's already on our roadmap, we'll letcha know when we succeed on EC2
21:24:52 <gregdek> huff, are your akis publicly visible?
21:25:01 <huff> gregdek: humm
21:25:14 <huff> when I upload them I can make them
21:25:21 <gregdek> bobmcw, do you have the ability to upload akis?
21:25:33 <huff> i can give bobmcw access to the ones i careate
21:25:38 <bobmcw> not that I know of.  thought that was reserved for amazon internal dudes and a few special outsiders
21:25:42 <gregdek> That's fine.
21:25:51 <gregdek> i just need to make sure we're not blocking.
21:25:59 <jforbes> Why make a bunch of AKIs public?
21:26:08 <gregdek> Well, i'd rather not, i guess.  :)
21:26:20 <gregdek> huff can make them selectively available, I guess?
21:26:29 <huff> yea just give me your ids
21:26:39 <bobmcw> huff: 6010-8304-0030 or team@oddthesis.org, depending on which they want
21:26:41 <gregdek> I mean, all of this is moot once jforbes gets the "proper" public AKI working.
21:26:45 <huff> or jforbes can do the dame thing now that he has access
21:26:55 <huff> bobmcw: they do nt exist yet
21:27:00 <bobmcw> 'k
21:27:07 <jforbes> IMAGE	ari-a949a6c0	F12/initramfs-2.6.32.9-70.fc12.i686.PAE.img.manifest.xml	125523088429	available	private		i386	ramdisk
21:27:10 <jforbes> IMAGE	ari-cd48a7a4	F12/initramfs-2.6.32.9-70.fc12.x86_64.img.manifest.xml	125523088429	available	private		x86_64ramdisk
21:27:13 <jforbes> IMAGE	aki-d749a6be	F12/vmlinux-2.6.32.9-70.fc12.i686.PAE.manifest.xml	125523088429	available	private		i386	kernel
21:27:16 <jforbes> IMAGE	aki-c148a7a8	F12/vmlinux-2.6.32.9-70.fc12.x86_64.manifest.xml	125523088429	available	private		x86_64kernel
21:27:22 <gregdek> Well, there we go.
21:27:22 <jforbes> So, the AKI and ARI are present, but not public since I just got perms fixed
21:27:41 <jonmasters> jforbes: how will security errata be handled?
21:27:43 <smooge> AKI amazon kernel interface?
21:27:45 <jforbes> Basically I haven't been able to test them.  I am happy to make them public right now if people have time to test
21:27:51 <bobmcw> amazon kernel image
21:27:55 <huff> jforbes: cool
21:28:11 <jforbes> jonmasters: that's a whole different discussion that is going to change any day now
21:28:22 <huff> jforbes: i dont see a problem with makeing them public now
21:28:24 <jonmasters> jforbes: right, just glad it's happening
21:28:34 <huff> its not likee ther is  whole lot of ppl that will rust to sue them
21:28:38 <huff> use
21:28:46 <gregdek> We will have lots of questions very soon, like mirrors and so on.
21:29:02 <gregdek> But they all come after this stuff.
21:29:13 <jonmasters> problem is once you have "official" Fedora images, then there's an expectation of "official" updates.
21:29:24 <gregdek> So let's call them "unofficial official images".
21:29:28 <jonmasters> please
21:29:37 <jonmasters> :)
21:29:44 <gregdek> jforbes, any way of labelling these bad boys "beta"?
21:29:48 <gregdek> Or something?
21:29:52 <gregdek> Maybe "unofficial" is better.
21:30:02 <gholms> Put "unofficial" in the bucket names?
21:30:04 <bobmcw> only by location really
21:30:10 <bobmcw> F12/beta/initramfs-...
21:30:21 <jforbes> gregdek: yeah, would just have to reupload them
21:30:22 <bobmcw> amzn has woefully little in terms of extra meta-data to express stuff
21:30:36 <gregdek> jforbes, is that a huge PITA?
21:30:41 <huff> here also need to be a level of secuirty checks b/c these are will be publicly acessable as soon as a user launches the image
21:30:42 <jforbes> gregdek: not really
21:30:48 * jonmasters thinks that's a good idea to ward off people thinking they'll get security updates
21:30:58 <gregdek> Then let's do that pls.
21:31:00 <huff> jforbes: there is a name attrubute you can change
21:31:00 <jonmasters> thanks jforbes
21:31:11 <huff> that may be easyer
21:31:15 <bobmcw> jforbes: could you mail details of final locations/aki/etc to bmcwhirt@ and mgoldman@ rht, that'd be awesome
21:31:18 <jforbes> jonmasters: a kernel update with a specific version in them should never imply security update
21:32:16 <gregdek> jforbes, eta on "unofficial" kernel upload?
21:32:30 <jforbes> gregdek: happening right now, just takes a few minutes
21:32:35 <gregdek> Rock on.
21:32:42 * jforbes only has 5mb upstream
21:32:51 <gregdek> yecch.
21:33:17 <gregdek> huff, bobmcw, assuming tomorrow morning start time, eta for images+docs?
21:33:32 <jforbes> seriously, like 15m
21:33:46 <gregdek> Well, I'm assuming folks are going home after this, LOL :)
21:33:49 <bobmcw> gregdek: aye, assuming things boot and survive, the mechanics are super quick
21:34:24 <bobmcw> and docs, I'm sure are on the site or blog somewhere.  just gotta get marek to drag'em to the top
21:35:06 <gregdek> Don't gimme "super super quick promise!"  Give me a day when I can see, say, a blog post with instructions in a tiny bow that even I couldn't screw up.
21:35:25 <gregdek> (Which I will then, I promise you, screw up anyway.)
21:35:53 <gregdek> Monday?  Tuesday?
21:35:56 * jonmasters has to run, later.
21:36:56 <gregdek> :)
21:37:00 <gholms> [a cricket chirps in the distance]
21:37:04 <huff> I can def do Monday if not end of day tomrrow
21:37:18 <gregdek> All right.  I'll take Monday.
21:37:22 <bobmcw> gregdek: sure, Monday
21:37:49 <gregdek> A note to the cloud list would be great for those playing the home game, also.
21:38:13 <bobmcw> "the" cloud list?  we have like 32 cloud lists
21:38:16 <gregdek> And then I'll use gholms' awesome euca2ools too!
21:38:17 <bobmcw> which do you refer to?
21:38:18 <gregdek> Sorry.
21:38:28 <gregdek> This is the #fedora-cloud SIG, so I assumed.
21:38:33 <gregdek> cloud@lists.fedoraproject.org
21:38:38 <gholms> Y'all have been using that where possible, right?  :)
21:38:39 <bobmcw> ah, not on that one
21:38:47 <gregdek> Its focus is simple:
21:38:54 <huff> gregdek: well can euca2ools do kernel upload and kernel assigment
21:38:59 <gregdek> Getting Fedora instances up on cloud services.  Starting with ec2.
21:39:07 <huff> I was going to use the tools form amazon
21:39:21 <gregdek> huff, prob not.  Use whatever processes you need to use.
21:39:26 <gholms> huff: If you can, use euca2ools for as much as you can and fall back to ec2-* when necessary.
21:39:26 <huff> rgr
21:39:52 <bobmcw> 'k, on that list now
21:39:57 <gregdek> So that's most of what I care about for this meeting, tbh.
21:40:14 <huff> lol
21:40:18 <gregdek> :)
21:40:27 <gregdek> I'm a simple dude.  I just want to get to the next step.
21:40:51 <gregdek> Which, to me, will be an analysis of these tools and a discussion on how to automate them into relend.
21:41:01 <jforbes> IMAGE	ari-7f47a816	F12/Beta/initramfs-2.6.32.9-70.fc12.i686.PAE.img.manifest.xml	125523088429	available	public		i386	ramdisk
21:41:02 <gregdek> But that's an Oxf13 discussion.  :)
21:41:04 <jforbes> IMAGE	ari-7747a81e	F12/Beta/initramfs-2.6.32.9-70.fc12.x86_64.img.manifest.xml	125523088429	available	public		x86_64	ramdisk
21:41:07 <jforbes> IMAGE	aki-7d47a814	F12/Beta/vmlinux-2.6.32.9-70.fc12.i686.PAE.manifest.xml	125523088429	available	public		i386	kernel
21:41:10 <jforbes> IMAGE	aki-7547a81c	F12/Beta/vmlinux-2.6.32.9-70.fc12.x86_64.manifest.xml	125523088429	available	public		x86_64kernel
21:41:13 <jforbes> Live and public
21:41:20 <gregdek> You're right.  That was quick.  :)
21:41:51 <jforbes> would be quicker if I would strip the kernel
21:42:02 <huff> jforbes: have you booted an image with those yet or are they raw and dangerious
21:42:03 <jforbes> In fact I probably should
21:42:06 <huff> dangerous
21:42:21 <jforbes> huff: raw and dangerous, just got the perms before the meeting
21:42:26 <huff> :)
21:42:40 <jforbes> so feedback appreciated
21:42:49 <gregdek> jforbes, can you echo those again with #info in front, for our notes?
21:42:51 <huff> i cant think of any reason they should not work but in ec2land stuff is usially harder that it seems
21:43:20 <gregdek> Or I can, I guess.
21:43:23 <huff> K i got to run
21:43:32 <gregdek> #info IMAGE ari-7f47a816 F12/Beta/initramfs-2.6.32.9-70.fc12.i686.PAE.img.manifest.xml 125523088429 available public  i386 ramdisk
21:43:37 <gregdek> (thx huff)
21:43:43 <gregdek> #info IMAGE ari-7747a81e F12/Beta/initramfs-2.6.32.9-70.fc12.x86_64.img.manifest.xml 125523088429 available public  x86_64 ramdisk
21:43:52 <gregdek> #info IMAGE ari-7f47a816 F12/Beta/initramfs-2.6.32.9-70.fc12.i686.PAE.img.manifest.xml 125523088429 available public  i386 ramdisk
21:43:58 <gregdek> #info IMAGE aki-7547a81c F12/Beta/vmlinux-2.6.32.9-70.fc12.x86_64.manifest.xml 125523088429 available public  x86_64kernel
21:44:06 <jforbes> gregdek: thanks
21:44:26 <gregdek> Whoops, did one twice.  Idiot.
21:44:40 * gholms shrugs
21:44:42 <gregdek> #info IMAGE aki-7d47a814 F12/Beta/vmlinux-2.6.32.9-70.fc12.i686.PAE.manifest.xml 125523088429 available public  i386 kernel
21:44:48 <gregdek> All right.
21:45:04 <gregdek> That's all I've got.  Does anyone else have anything they want to talk about?
21:45:08 * gholms raises hand
21:45:11 <gregdek> Shoot.
21:45:15 <gholms> #info euca2ools-1.2-2 is in updates-testing with lots of bugfixes; please test and provide feedback in bodhi
21:45:53 <gholms> I can't push the update without karma, so while you folks are building these images, invoking instance, and whatnot, please use euca2ools when you can and file any needed bugs.
21:46:41 <gholms> https://admin.fedoraproject.org/updates/euca2ools-1.2-2.fc12
21:46:45 <jforbes> gholms: you can, it is just frowned upon
21:47:02 <gholms> How's that?
21:47:08 <gholms> Oh, never mind.
21:47:11 <gregdek> LOL
21:47:23 <gregdek> #topic New update of euca2ools, please test for karma
21:47:38 <gregdek> Oh, well, that was unnecessary.
21:47:41 <gregdek> Ah well.
21:47:47 <gregdek> Anything else on that front, gholms?
21:47:51 <gholms> So euca2ools 1.2 as released can't do block device mapping.  At all.
21:47:55 <gregdek> Oo.
21:48:07 <gregdek> #info euca2ools 1.2 does no block device mapping
21:48:12 <gregdek> Is that a regression?
21:48:17 <gholms> #undo
21:48:25 <gholms> Crap, can you undo that?
21:48:40 <gholms> euca2ools 1.2, *as released*, can't do block device mapping.
21:48:42 <gregdek> Why?  Did I speak out of turn?
21:48:58 <gholms> The updated version has the bugfix for it.
21:48:59 <gregdek> Just clarify with another info, I guess.  Sorry.  :/
21:49:27 <gholms> #info euca2ools 1.2-2 fixes block device mapping errors
21:49:31 <gregdek> So euca2ools 1.2.2 is a fix to 1.2's inability to do block device mapping?
21:49:36 <gregdek> Got it.  Thx.  :)
21:49:53 <gholms> It has a few other miscellaneous bugfixes, too.
21:50:16 <gregdek> Anything further?
21:50:20 <gholms> I'm not going to push an untested package, though, so where possible I ask that people use it.
21:50:32 <gholms> That's it for me.  Repetition is good for memory.  :)
21:50:33 <gregdek> Yep.  Fedora thanks you.  :)
21:50:40 <jforbes> gholms: very much appreciated
21:51:02 <gregdek> Any other topics?
21:51:20 <gholms> Any image builders still here?
21:51:33 <gregdek> I know huff is gone... bobmcw?
21:52:09 <gholms> If you run into an issue where images go from pending directly to terminated, we need help debugging bug 575258.
21:52:10 <smooge> gregdek, I was just looking at the cloud-utils package from Ubuntu
21:52:19 <gholms> .bug 575258
21:52:24 <zodbot> gholms: Bug 575258 Procedure to bundle and install image fails - https://bugzilla.redhat.com/show_bug.cgi?id=575258
21:52:35 <smooge> not sure if its something people have talked about before
21:53:34 <gregdek> smooge, it has been discussed.
21:54:14 <smooge> gregdek, okie dokie
21:54:16 <gregdek> gholms, can you #info that?
21:54:21 <gregdek> smooge, what have you learned?
21:54:38 <gregdek> Got time to share quickly?
21:54:46 <gregdek> (We lose the channel in 5min)
21:54:54 <smooge> well I just found out about it 10 minutes ago.. they have various utilities to make ubuntu quickly via eucatools
21:55:02 <gregdek> #topic cloud-utils in Ubuntu
21:55:03 <smooge> I will know more by next meeting
21:55:05 <gholms> #info If your instances go directly from pending to terminated, comment on bug 575258
21:55:10 <gholms> Gah!
21:55:13 <gregdek> Doh!
21:55:15 <gregdek> Sorry gholms.
21:55:17 <gregdek> Sigh.
21:55:19 <gholms> No worries
21:55:23 <gregdek> I'm a terrible meeting bot host.  :/
21:55:30 <gregdek> Oh well.
21:55:47 <gregdek> So smooge, do you wanna just write up a report for cloud list?
21:55:53 <smooge> yes will do so.
21:55:56 <gregdek> That would seem *really* useful.
21:55:56 <smooge> they do do man pages
21:56:09 <gregdek> #action smooge will report on Ubuntu cloud-utils onlist
21:56:11 <smooge> will have it ready by tomorrow
21:56:19 <gregdek> No rush, but thank you.  :)
21:58:13 <gholms> Anything else?
21:58:43 <smooge> not for me
21:58:48 <smooge> have to go for a bit
21:58:49 <gregdek> All right.
21:58:57 <gregdek> THen I'm gonna call it.
21:59:01 <gholms> Thanks for coming, everyone!
21:59:05 <gregdek> Thanks all!
21:59:07 <gregdek> #endmeeting