21:00:11 #startmeeting Cloud SIG 21:00:11 Meeting started Thu Dec 9 21:00:11 2010 UTC. The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:13 rbergeron: Relish! 21:00:14 well you don't want a new one... 21:00:29 * rbergeron passes a vegan-friendly carrot to skvidal 21:00:35 #meetingname Cloud SIG 21:00:35 The meeting name has been set to 'cloud_sig' 21:00:40 #topic Roll call 21:00:45 hey, I'm vegan too, where's my love? 21:00:46 Yo. Who's here :) 21:00:51 I'm here 21:01:00 * jforbes is here 21:01:03 * jdarcy <- present 21:01:03 * rbergeron isn't really sure that a carrot is love, it's more like "robyn's weak excuse for a vegan food" 21:01:05 * mmorsi1 is here 21:01:13 bacon 21:01:15 mgoldmann ;) 21:01:33 * rbergeron assures the vegans that she does love them, so as not to offend. 21:01:35 * jsmith is here 21:01:48 hey mmorsi1. 21:01:52 * obino is here 21:01:52 uhm? :) 21:01:52 * sgordon is here 21:01:54 here! 21:01:54 rbergeron: howdy 21:01:57 sup 21:02:10 * rbergeron waves at sdake 21:02:16 clalence can't make it today so i'm going to try and take his place 21:02:24 course noone can replace clalence ;-) 21:02:28 awesome. thanks for joining :) 21:02:36 np 21:02:36 Cool... looks like we've got a great set of folks here :-) 21:02:44 no no. you'll become addicted and you'll both want to come ;) 21:02:50 jsmith: indeed. 21:02:58 #topic EC2 21:03:04 hehe 21:03:06 * jsmith has been playing with EC2 a bit today :-) 21:03:23 * jgreguske waves 21:03:26 jforbes, gholms, brianlamere, how goes it? 21:03:27 (and found that the python-boto package in updates-testing works much better) 21:03:27 Too bad zaitcev isn't here. Seems to be the hero of the day. 21:03:33 oh. 21:03:37 Oh? 21:03:40 jdarcy: do tell 21:03:54 Fixed a bug in euca2ools that was annoying people a bit. 21:04:00 Well, we have a couple of things to discuss for EC2 21:04:13 jforbes: go ahead :) 21:04:16 he's here! 21:04:17 :) 21:04:17 oh look. THERE's our hero. 21:04:22 too bad that guy isn't here that's here 21:04:31 * rbergeron checks to see if this is a record cloud-sig meeting attendance 21:04:44 #chair jforbes jsmith 21:04:44 Current chairs: jforbes jsmith rbergeron 21:04:48 #chair gholms 21:04:48 Current chairs: gholms jforbes jsmith rbergeron 21:04:49 just in case this was the bug https://bugs.launchpad.net/bugs/665667 21:04:52 First, there has been some discussion on how we have a testable image, and avoid things like the httpd issue. Particularly since httpd isnt in the default issues 21:04:59 * rbergeron nods 21:05:03 err default images... reading and typing is bad 21:05:25 yeah, I can tell you I ran in to the problem with far more than just httpd ;) 21:05:33 jforbes: suggestions? 21:05:33 So I think we should discuss what we really want in the default images, perhaps there should be a basic set of services 21:05:33 Well, it's not so much that we want to test httpd in particular -- just test *something* to make sure we don't run into a similar issue 21:05:48 jforbes: shall we do that now? 21:05:53 I think we have enough people, fo sho. 21:06:02 yes, stand up an entire stack, and run lots of stuff. 21:06:09 I thought it should be @core 21:06:09 jsmith: right, so httpd was just an example that just happened to bite us 21:06:17 or at least, after you get to anytihng else you have to say :) 21:06:28 Note however: this was actually an issue that is known to exist with their hypervisors, it just was known...a while back. 21:06:35 #info it would be helpful to discuss a basic set of services, and what that would entail. 21:06:43 * jsmith thinks a minimal package set is the way to go, and let folks add their favorite packages on top 21:06:50 @core is a basic set of services. Let's use that. 21:07:00 I know I'm new here, so maybe this is common knowledge, but are we using yum for package management on everything, or just the basics 21:07:03 yes - truly, let it be minimal still 21:07:07 rfelsburg: yum 21:07:11 mgoldmann: @core was the plan, but it brings up a good point. What is tested, how do we get this tested? 21:07:28 rfelsburg: yes, it is intended to be transparent, and behave like a normal fedora install 21:07:33 are we using it for major items like apache, ssh etc.? 21:07:41 well, it seems boot isn't sufficient :) 21:07:51 rfelsburg: Not by default, though people can certainly install it. 21:08:12 right, so the old criteria was boot and run yum 21:08:29 IMO, we should install enough to let get people a shell on it and also have selinux support. 21:08:33 obviously ssh gets tested as well, you can't run yum if you can't ssh into it 21:08:34 we can try to define list of services users will most probably install and try to create basic test for them maybe 21:08:39 rfelsburg: the only things on the image are the things you need to have on the image to install other things on the image. :) like, ssh 21:08:48 mgoldmann: I agree with that. 21:08:52 brianlamere: what I was getting at, was anything more than a minimal install brings lots of dependencies that aren't always removed when the package itself is. so i would go extremely limited essentially ssh and security 21:08:58 with appropriate firewall rules presetup of course 21:08:59 apache is on the top I think :) 21:08:59 jforbes: so we're looking at two things here, right? 21:09:01 Selinux is kind of a big feature for Fedora, so having support for that out of the box would probably be a good idea. 21:09:09 #1 being - What is the basic package set to install 21:09:15 +1 to SELinux 21:09:16 rfelsburg: that's fixed a lot better now in yum 21:09:18 So leave the images as @core, and come up with a test plan that includes installing/testing some basic services? 21:09:19 rfelsburg: upstream 21:09:24 #2 being - what are the most likely things users will want to yum install afterwards. 21:09:25 jforbes: +1 21:09:27 rfelsburg: yup, that's what's there 21:09:28 And how to test them. 21:09:29 jforbes: That works for me :-) 21:09:33 jforbes: +! 21:09:37 +1 even 21:09:38 :) 21:09:50 #agreed leave images as @core and come up with a test plan that includes instlling/testing some basic services. 21:09:55 yum and httpd come to mind as things one might immediately install 21:09:57 is it possible we could use the user_data like some other distros do with the #! check? 21:10:00 s/install/use/ 21:10:07 skvidal: fixed ala f14? cause i was still seeing some prettty large holws with regards to dependency removal in f12 21:10:19 well the reality is, Fedora at EC2 will be used primarily for a relatively limited number of tasks. LAMP, etc. 21:10:21 skvidal: The hope is to port cloud-init (the system they use) to RH-type distros. 21:10:21 rfelsburg: it's fixed in rawhide - it'll find it's way back to f14 21:10:26 rfelsburg: and you can do yum history undo 21:10:27 skvidal: yes, we can 21:10:27 probably want to test stuff that isn't defined by the package set too, like selinux on/off, fs size 21:10:39 gholms: that'd be what I'd like to see 21:10:39 For the specific case of the negative-segment-offset bug, I suspect anything which uses thread-local storage (at least) would tickle it, so we might be able to go for something lighter-weight than httpd for regression purposes. 21:10:40 skvidal: I was going to do that but then I got bogged down in moving cross-country. 21:10:42 rfelsburg: dependency hell has been getting less hell and more heck as time goes on 21:10:50 So anyone want to take a stab at the test plan? or even at the list of services to be tested? 21:11:02 skvidal: thanks I'll look into it. 21:11:11 I think if someone wants to take a crack @ a list of services on the mailing list, that would be good. 21:11:14 jdarcy: we've solved that particular issue, though - the trick is what is sufficient for finding new ones 21:11:16 And we can add on as needed. 21:11:21 jforbes: I can give it a start 21:11:21 skvidal: I'm not sure what goes on at a python hack-a-thon, but if that sounds like a good candidate for it then that might be a good time. 21:11:23 Or alternately, we can do it now. 21:11:29 jsmith: thank you sir :) 21:11:31 brianlamere: yea installing was never an issue, getting yum to remove the same deps it installed was a problem in fedora12 for me. 21:11:32 #action jsmith to take a first stab at a test plan 21:11:50 rfelsburg: http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ 21:11:54 is there any merit to having puppet in the base build to combine yum for package install and puppet for service/system config? 21:12:06 sloranz: you took the question right out of my mouth :-) 21:12:11 sloranz: puppet drags in the whole world in deps 21:12:17 rfelsburg: that's more a general fedora issue however, not a fedora-cloud issue; we're a specific task group here ;) 21:12:21 having ruby on there feels extra heavyweight 21:12:21 for base build? -1 21:12:30 sloranz: People who automate to that extent should really be rolling their own images based off of our stock one. 21:12:30 but makes configuring other services alot easier 21:12:34 We should probably throw in any packages that are related to being in EC2, such as boto for S3. 21:12:40 jsmith: thanks, that would be great! 21:12:54 brianlamere: sorry that related to how minimal of an image was installed by default, im advocating for fairly minimal 21:13:04 jdarcy: What would be the point? 21:13:10 skvidal: touchè 21:13:23 when I first joined the list I did so to try to promote cloud-ish tools that would be helpful to me personally ;) so either puppet, or the openssh-ldap stuff, etc 21:13:37 gholms: To test functionality that people using those images are very highly likely to use. 21:13:38 rfelsburg: ah, yeah, it's really quite minimal 21:13:39 this may make building / testing these images alot harder but would it make sense to have multiple fedora images with different stacks ontop 21:13:49 #info LOTS OF SUGGESTIONS for test plans / what to be tested in this meeting log. 21:13:58 rbergeron: :P 21:14:06 spins of specific target types are interesting but create a big test matrix 21:14:10 jdarcy: I can see that as an argument for test cases, but not packages to go in the default install. 21:14:14 gholms: just noting for people who skim the minutes ;) 21:14:17 sdake: agreed 21:14:18 rbergeron: Yep 21:14:18 that is essentially appliance model 21:14:25 Why not just script the installation of different server types. 21:14:32 instead of building it into the image itself. 21:14:39 we would do well to test "one" build first :) 21:14:47 rfelsburg: That's what boxgrinder is supposed to do. 21:14:52 sdake: I agree... let's get *something* tested first 21:14:54 rfelsburg: puppet might make that scripting easier 21:15:01 aight that makes sense 21:15:03 it would def. make it easier. 21:15:12 just create meta-packages that create a particular type of appliance. Spin up a micro, install meta package...should be pretty fast? 21:15:14 if you use the cloud_init scripts 21:15:21 then you don't need the puppet-specificness 21:15:23 you can bootstrap 21:15:25 mmorsil: Thats what I do in our production environments. 21:15:25 from your boot 21:15:33 brianlamere: we have comps groups, why build meta-packages? 21:15:34 skvidal has a good point. 21:15:47 jeremy: b/c wheel reinvention rocks? 21:15:51 skvidal: clearly. 21:16:00 jeremy: because comp groups are for anaconda to use. I'm talking about unit testing post-install 21:16:06 wheel is perfect, no point in reinventing that :) 21:16:19 * jeremy mumbles something about boxgrinder's config file format that mirrors nothing else in the world and then tries to use that to create a kickstart config 21:16:19 brianlamere: yum groupinstall packagegroup 21:16:24 brianlamere: yum groupinstall dude 21:16:24 brianlamere: comps groups are used by ANY thing in yum 21:16:28 brianlamere: and can be in ANY yum repo 21:16:32 yum install @group too 21:16:35 lol 21:16:35 do comp groups really handle setting up a particular environment well? it's not just everything in a packagegroup :) 21:16:47 JFORBES: anything else on ec2? 21:16:53 Heh 21:16:54 * rbergeron tries to wrangle a bit of order to the meeting ;) 21:17:20 we need a digital conch shell (from lord of the flies) 21:17:21 rbergeron: not for the moment 21:17:31 but i digress ;-) 21:17:40 how are the things as far as working around amazon's xen issue going? 21:18:02 well, for that matter I suppose you could just install almost everything, and not worry about it ;) sorry, I guess I use the wrong tools for jobs sometimes ;) I use meta-packages because they help me pull from additional repositories. so comp groups then, sure ;) 21:18:28 Oh, right, amazon's issue isn't so much the issue anymore, we have a fedora issue, and I didnt get back to it until today. I think I have a workaround, just need to test it 21:18:28 gholms: yum package groups tend to be extremely encompassing, and oft quite a bit more than is needed. 21:18:44 rfelsburg: yum-groups-manager - make whatever you want 21:18:45 jforbes: awesome. thank you 21:18:52 jforbes: Just enabling nosegneg? 21:19:16 my vote for for testing stuff - I would execute script pushed as user_data, what we have in this script is another story 21:19:17 jforbes: If you'd like, send a brief description of the problem to the list, so that others can help hunt it down 21:19:18 brianlamere: comps groups can pull from multiple repos, too 21:19:24 brianlamere: it's not restricted to a single repo 21:19:46 mgoldmann: so put cloud_init tools in place to do that at boot? 21:20:03 skvidal: thansk 21:20:07 I'm not familiar with this, lemme take a look 21:20:09 gholms: that's the easy part... getting boxgrinder to work with the broken augeas in f13 is the issue, building f14 augeas for f13 seems to be the fix. Eventually (once boxgrinder is in the distro) we will need our own build images 21:20:21 I seee. 21:20:37 Can someone please help me look into porting cloud-init to an RH-type distro? It has a bunch of Ubuntu-specifics. 21:21:00 gholms: I can help. 21:21:14 jforbes: stay in touch with fedora rel-eng, they're looking at using koji to build images 21:21:14 jsmith if your interested in testing and having some basic idea that the system's posix apis are operating properly, might have a look at http://ltp.sourceforge.net/ 21:21:24 jforbes: I'll try to build new meta-appliance based on F14 and release it shortly 21:21:33 im sure that would have caught this http image problem 21:21:37 #action rfelsburg and gholms to look into porting cloud-init to a RH-type distro 21:21:40 this should help you a lot I hope 21:21:51 sdake: maybe 21:21:53 * rbergeron looks around for other EC2 related hands in the air 21:22:04 gholms: I could help, didn't I send you an email on it? I don't know that I got one back 21:22:14 brianlamere: I received nothing. :( 21:22:15 gholms: most - but not all of what cloud_init does is in rc.local in the ami's that are listed on the fedora page 21:22:27 gholms: well, I'll try again :) 21:22:29 sdake: the biggest problem with the httpd issue is only some hosts will show it, so luck of the draw 21:22:49 skvidal: Basically. It would be good to get things in line with $other_popular_distro. 21:22:53 jforbes: yeah, that's the issue. because some of their old hypervisors *are* patched 21:22:53 gholms: sure 21:23:01 jforbes could set automated test on variety of vm types, such as xen, kvm, vmware 21:23:19 jforbes: that would be me that jgreguske is refering to 21:23:20 as part of build process 21:23:21 is there a ticket open for the httpd issue. I'm working with a prod environment in the cloud, and can maybe help. 21:23:33 jforbes: id really love a kickstart file for ec2 images 21:23:44 dgilmore: okay, time to talk after this? 21:23:50 jforbes: yep 21:23:59 dgilmore: yeah, maybe we can hang on to that for later in the meeting or afterwards 21:23:59 rfelsburg: https://bugzilla.redhat.com/show_bug.cgi?id=651861 21:24:05 .bug 651861 21:24:07 gholms: Bug 651861 hang in readdir64_r on i686 in EC2 - https://bugzilla.redhat.com/show_bug.cgi?id=651861 21:24:26 that can realistically be tested locally, too - so that it's not really luck-of-the-draw. Perhaps just make local servers that are old, unpatched, and 32bit ;) 21:24:44 #topic Boxgrinder 21:24:56 hey, that's me! 21:24:57 I'm moving forward, folks, just trying to hold a lot of us together today :) 21:25:01 the 64bit host machines shouldn't really (err...) have a problem ever, with the built-in virtualization 21:25:02 * rbergeron is delighted at the turnout. Thanks everyone! 21:25:12 mgoldmann: How goes the BG feature? 21:25:30 almost all packages were approved 21:25:33 i was told there'd be punch and pie :-p 21:25:49 waiting for only one approval, everything else was built for F13/F14/rawhide 21:25:53 mmorsi1: I'm gonna have to talk to clalance about the promises he's making you ;) 21:26:00 https://fedoraproject.org/wiki/Features/BoxGrinder#Current_status 21:26:01 hehe 21:26:10 mgoldmann: does it need poking along / reviews from someone? 21:26:34 only waiting now for https://bugzilla.redhat.com/show_bug.cgi?id=652414 21:26:49 of course euca2ools needs to be solved too 21:27:07 #topic need a review on https://bugzilla.redhat.com/show_bug.cgi?id=652414 for BG - last one! 21:27:12 ugh 21:27:13 #undo 21:27:13 Removing item from minutes: 21:27:29 #topic Boxgrinder 21:27:32 but this is on it's own path, gholms and euva2ools are working on that 21:27:46 david is testing the fix 21:27:46 #info need a review on https://bugzilla.redhat.com/show_bug.cgi?id=652414 for BG - last one! 21:27:56 thanks to zaitcev we have a patch for it 21:28:08 this will be included in upstream euca2ools 21:28:16 * rbergeron bows to zaitcev 21:28:18 next step is to release updated package in Fedora 21:28:20 Wait, what? 21:28:26 no? :) 21:28:41 Oh, that patch. 21:28:45 Yay, Pete! 21:28:54 yes, patch :) 21:29:00 It needs... work. When upstream merges a fix I will use that one. 21:29:18 Mitch e-mailed me with: "I'm in the process of refactoring all of the euca2ools code so I will incorporate your suggestions in that new version. I'll patch the current euca2ools main, as well." 21:29:20 yes, this is what I'm trying to write :) 21:29:53 * gholms feel bad for neil, its original writer 21:30:18 so, the great news is that the euca2ools issue will be solved, finally :) 21:30:27 yes! 21:30:30 :) 21:30:31 The problem is that he does not want to use tee(1). So most likelye he'll reimplement something very similar to my patch for 1.3 branch, e.g. we'll waste 2GB or 10GB of temp space per run. 21:30:32 mgoldmann: very nice. thanks to all for helping, been a big team effort. 21:30:37 shortly after this - I'll submit last 3 (optional) packages 21:30:40 #info euca2ools-1.3.1-4 should fix the bug that prevents its images from working on Amazon EC2 21:30:51 He cannot use my patch as-is because I do not have Eucalyptus contributor agreement. 21:31:17 zaitcev: He can't use it as-is anyway because it doesn't apply to the current code. No worries. ;) 21:31:47 2G to 10G per run? is that something we need to worry about? some small heads won't have 10G of tmp space avail... 21:32:11 Otherwise I'd have given mgoldmann an interim-fixed RPM hours ago. 21:33:33 Anyone running F13 that has a EC2 account? 21:33:36 * rbergeron looks to see if anyone has an answer to brianlamere's q before moving on :) 21:34:00 I have an F13 guest 21:34:05 brianlamere: I'm more concerned about speed. That's a lot of time lost to disk writes. 21:34:33 sorry, thought that was a rhetorical questions. What's the usual swing on log disk usage 21:34:56 I take that back, I also have an F13 host, I just need to power it up 21:35:00 maybe, but keep in mind that a micro is only starting out with 10G total ;) 21:35:09 gholms: I'm sure I could rustle up an F13 box (or vm)... why? 21:35:28 jforbes: I could share my old F13 images to you, but I deleted them a few days ago ;) 21:35:37 I need someone to install euca2ools-1.3.1-3 from updates-testing and make sure "euca-describe-images -a -U http://ec2.us-east-1.amazonaws.com/" works both with and without the trailing slash. 21:35:48 The F13 package needs one more +1 to go stable. 21:35:59 gholms: do this yourself :) 21:36:10 mgoldmann: It's bad form to +1 your own updates... 21:36:14 .bug 658560 21:36:16 gholms: Bug 658560 fail with a trailing slash - https://bugzilla.redhat.com/show_bug.cgi?id=658560 21:36:20 well :) 21:36:22 https://admin.fedoraproject.org/updates/euca2ools-1.3.1-3.fc13 21:37:14 why not just use the JEOS Fedora 13 image, btw? 21:37:14 That testing can take place offline; we don't need to wait for it here. 21:37:33 jforbes: ^ 21:38:00 okay, will do 21:38:14 Thanks 21:38:18 gholms: trying right now 21:38:21 but continue on 21:38:28 Thanks to you, too. :) 21:38:33 Well, one quick "fix" is to pipe tar|gzip and store tar.gz on disk, then do gunzip|sha1. This trades CPU for disk space and I/O. 21:38:44 didn't even think you could +1 your own updates 21:39:20 mmorsi1: The next time bodhi gets updated you won't be able to any more. 21:39:21 * mgoldmann tried this 21:39:41 ah 21:40:47 okee dokee. 21:40:51 does it take a while, just sitting there? 21:40:59 * rbergeron shall move on, unless there are any other BG things 21:41:01 imagine since the ec2 image list is large it will 21:41:01 What tool are we talking about for the 2-10g disk usage 21:41:09 ah there it is 21:41:24 yes seems to work 21:41:26 wife is making me eat, ttyl 21:41:36 zaitcev: Thanks for posting that patch! 21:41:37 rbergeron: fwd 21:41:40 zaitcev: have a good one :) 21:41:48 zaitcev: laters! 21:41:51 mgoldmann: fwd? :) 21:41:53 forward? 21:42:05 yah, next topic :) 21:42:06 #topic CloudFS 21:42:06 mmorsi1: Both with and without the trailing '/'? Could you add +1 to the update when you get a chance? 21:42:12 jdarcy: speaketh :) how goes it 21:42:13 Ooh, CloudFS! 21:42:25 Churning away. 21:42:48 I had some conversations with the upstream folks about repos and such, they need to get back to me. 21:42:50 gholms: http://fpaste.org/k8cq/ http://fpaste.org/nIOq/ 21:42:56 that all i need to verify? 21:43:02 truncated the list 21:43:08 jdarcy: we did get you a repo, right? I think ke4qqq did that. 21:43:21 mmorsi1: Yeah. Just make sure it also works without the trailing '/' as well. 21:43:24 a local one that is :) 21:43:26 Yes, the Fedora repo does exist, but somehow I missed the mail-list-admin email. 21:43:37 hmmm 21:43:41 gholms: ya the first one was w/out the / and the 2nd was with 21:43:41 I'll start pushing up content next week probably. 21:43:51 k i'll give u the bump 21:43:55 #info jdarcy will start pushing up content next week probably. 21:44:12 Are you using repos.fedorapeople.org, or something else? 21:44:31 gholms: CloudFS on fedorahosted 21:44:37 http://git.fedorahosted.org/git/?p=CloudFS.git 21:45:11 Also need to start putting together some web content describing the pieces. 21:45:12 Oh for git hosting. Got it. 21:45:20 jdarcy: yes plz. :) 21:45:43 It's all coming along, just advancing on a broad front. ;) 21:46:11 gholms: bumped 21:46:16 jdarcy: when we get closer to Beta/GA, there's also some room for marketing to come do interviews/feature profiles there. 21:46:22 just as an FYI. 21:46:26 * rbergeron will put on her marketing team hat for that 21:46:36 mmorsi1: Thanks 21:46:39 That'll be good. 21:46:41 np 21:47:05 #topic Deltacloud 21:47:21 Anyone around still from deltacloud that might be able to talk about IF this might be going into F15? 21:47:37 rbergeron: sure, we're beginning to work on it 21:47:44 still very preliminary 21:47:47 but that is the goal 21:48:23 mmorsi1: do you know if that's hoping to be on Featurelist? 21:48:30 unfortunately don't have too much to report other than that, but yes we are aiming to get this included and supported on both F15 and RHEL6 21:48:49 * rbergeron notes that feature submission deadline is 1-25 21:49:15 mmorsi1: any packages to help to test or something? 21:49:18 mmorsi1: is there anything blocking anyone as far as packages, etc? 21:49:26 * rbergeron notes that mgoldmann is reading her mind 21:49:27 hrm not sure about the feature, but will add an item to my backlog to find out b4 next cloud-sig mtg 21:49:29 spoooooky 21:49:31 the prelim packages probably need a review 21:49:41 #link http://fedoraproject.org/wiki/Schedule 21:49:42 * gholms hands rbergeron a tinfoil hat 21:49:47 NO! that's not the link i want. 21:49:57 #link http://deltacloud.org/page/Packaging_list 21:50:00 lol 21:50:00 Undo? 21:50:01 ^^^ is the link I want. 21:50:11 It's okay. Having the schedule link isn't going to hurt :) 21:50:12 we do have some packages that still need some love, but afaik they are being worked on 21:50:24 rbergeron: uh, it's good you didn't pasted other link... 21:50:30 wouldn't hurt to get additional eyes to help out w/ the process tho 21:50:36 mmorsi1: do you know if that list is relatively up to date? 21:50:57 also w/ ruby support on fedora in general, lot of discussion on ruby-sig pertaining to various issues 21:51:01 wow, it looks like it - last updated dec. 8 21:51:11 yes that shuold be up2date 21:51:14 ;) 21:51:40 abadger1999: do you still have folks interested in doing ruby reviews? 21:51:44 we are making a point of not including additional dependencies w/out packaging them and getting started on teh fedora submission process first 21:51:59 mmorsi1: that is good news :D 21:52:07 woot! yes 21:52:17 believe me, i know ;-) 21:52:35 * rbergeron gives that 6 thumbs up 21:52:50 way to easy in the ruby world to pull in the latest greatest gem which hasn't been vetted yet, suppose thats the problem w/ being on bleeding edge 21:52:53 * rfelsburg worries that rbergeron has 6 thumbs 21:52:59 but always looking for improvements and new contributers 21:53:49 mmorsi1: if you can let us know next week (since I know both you AND clalance will want to come) what thoughts are as far as F15 feature list, that would be great. 21:54:11 I know that clalance was talking about cloud engine as well, but I think that is more up in the air. 21:54:19 sure thing, that is an action item of very high priority on my backlog 21:54:42 #action mmorsi1 to give an update next week on deltacloud feature list intentions for f15 21:54:45 thanks! 21:54:49 np 21:54:52 #topic Any other business? 21:55:14 what's the status on the mirrors? =D 21:55:28 fyi -- I'm probably going to be writing the dirt simple ami-creator script that uses python-imgcreate, takes a kickstart config and can give you an ami out the other side 21:55:40 jeremy: Great! 21:55:42 jeremy: you should also talk with fedora rel-eng 21:55:54 brianlamere: Anyone have a way to sync a S3 bucket with a local directory or HTTP mirror? 21:55:57 or stick around with me, dgilmore and jforbes after the meeting 21:56:03 * rbergeron nods 21:56:23 clalance would be also be amiss if i didn't mention oz https://github.com/clalancette/oz 21:56:31 * rbergeron will just change the topic over to EC2 / rel-eng in a few minutes. 21:56:34 since, you know, we've kind of standardized on kickstart configs as a way to describe images for the world of fedora 21:56:37 mmorsi1: yeah, i saw his email today. 21:56:38 don't know too much about it myself, but check it out! 21:56:51 #info check out https://github.com/clalancette/oz 21:57:12 gholms: I think I was supposed to do that at some point, wasn't I. Yeah. I failed; had some stuff come up 21:57:36 brianlamere: I think it kind of stalled at that point. :-\ 21:57:45 gholms: s3cmd can sync a local dir to a bucket, can't it? 21:57:48 sowwe. Yeah, was personal stuff 21:57:52 Yeah, that looks kind of neat! 21:58:17 I think I need to talk with clalance about oz :) 21:58:19 brianlamere: Can s3cmd sync do it? 21:58:31 jeremy: any of the tools out there tend to break if you send much through it...they also don't really do comparisons, they just copy over 21:58:54 brianlamere: That's not what http://s3tools.org/s3cmd-sync seems to indicate. 21:59:03