19:01:01 #startmeeting Cloud SIG 19:01:01 Meeting started Fri Dec 16 19:01:01 2011 UTC. The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:01:08 already? 19:01:17 #meetingname Cloud SIG 19:01:17 The meeting name has been set to 'cloud_sig' 19:01:27 #topic Who's Cloudy? 19:01:32 #chair gholms 19:01:32 Current chairs: gholms rbergeron 19:01:34 HI SMOOGE 19:02:21 * jforbes is here 19:02:23 * spstarr is here 19:02:25 lalala 19:02:31 * kkeithley is here 19:02:34 hey mgoldmann_ :) 19:02:39 * rbergeron didn't realize you were still about today 19:02:47 * mgoldmann_ is here with his new laptop 19:02:53 mgoldmann_: ooh, what did you wind up getting 19:03:09 drinking beer, configuring fedora, usual evening 19:03:41 excellent 19:03:51 :) 19:03:57 #topic OpenNebula 19:04:04 spstarr: take it away, sir :) 19:04:29 rbergeron: I'd like to see who can help out with Rubygem stuff for OpenNebula 19:04:41 and other items the main developers are in Spain (not on right now) 19:05:16 yarghhh. as in making gems or just reviewing? 19:05:16 We have a wiki page for what needs to get done. I have all the rubygems packaged but they need to be converted to RSpec 2 support for Fedora 17 will be using Ruby 1.9.3 it seems. 19:05:37 spstarr: can you link the pages into the meeting notes real quicklike? 19:05:37 reviewing and porting there's a lot of them but I've done the packaging already so it's tweaking 19:05:40 #chair spstarr 19:05:40 Current chairs: gholms rbergeron spstarr 19:06:04 https://fedoraproject.org/wiki/Features/OpenNebula 19:06:25 we touched on this previously in 19:06:27 http://meetbot.fedoraproject.org/fedora-meeting/2011-09-02/cloud_sig,_where_the_mustard_indicates_awesome.2011-09-02-18.59.html 19:06:53 rbergeron: there was an action item for you to ask the RubySIG folks to update the packaging guidelines so we'll know what they want 19:07:31 hola rbergeron 19:07:40 heya dgilmore. 19:07:42 I will be updating the wiki now that I'm on vacation and will be focusing on all efforts with the OpenNebula team on getting the required changes in for Fedora 17 19:07:50 spstarr: well, i forget things 19:07:53 ;) 19:08:24 they developers have a channel on freenode in #opennebula as well 19:08:28 spstarr: i mean, i'm not exactly ruby friendly - it might be easier to actually have you ask them to update things since ... you know what you're looking for, and i would pretty much be just on a witch hunt, since i'm not actually capable of doing those fancy technical things 19:08:28 sorry, the 19:08:42 i'm not sure what all needs to be updated? 19:09:04 I will ask Vit to publish the changes to the Ruby Packaging guidelines then 19:09:05 * rbergeron wonders if anyone here is also from rubysigland 19:09:58 * mgoldmann_ just lurks at the SIG, but he doesn't consider himself as part of it :) 19:10:01 * rbergeron isn't sure if the ruby folks can just update packaging guidelines either or if they need to go through the packaging committee (/me looks at maybe spot or toshio for guidance here) 19:10:22 through the packaging committee 19:10:34 what needs changing? 19:10:38 can we have an action for that? 19:10:54 spstarr: what needs changing? 19:11:03 i'm not clear on what needs changing or updating 19:11:35 they are removing the ruby-rubygem sub package, RSPec 2.x testing standards and im not sure what else, but there is probably some more changes I think. 19:11:59 Vít Ondruch is the Ruby SIG lead 19:12:15 here's a recent email thread 19:12:17 "I have uploaded updated version of Ruby 1.9.3 packages into my testing 19:12:17 repository. They are probably very close to the shape of Ruby I'd like 19:12:17 to see in future Fedoras. The main changes are" 19:12:35 ah -- is this needed as part of the upgrade to ruby-1.9? 19:12:38 .. they are preparing to move to a new version and this is going to to effect all rubygems 19:12:39 yes 19:12:50 so we need them to decide if they are committing to a new version 19:12:52 They'll need to get whatever changes they need to the fpc 19:12:53 before you move forward? 19:13:00 but they haven't done anything yet. 19:13:20 rbergeron: yes more or less, because my packages as they are now would be 'ok' 19:13:29 But they haven't talked to us yet. 19:13:31 aside from any additional reviews needed 19:14:26 well, and if it affects all rubygems, I'd expect that they would be filing a feature for it as well 19:14:40 I have 2 rubygems that have recently been approved by Vit and others rubygem-addressable and rubygem-idn which will be pushed into git this weekend 19:15:01 those are dependencies for other Fedora feature 19:15:38 * rbergeron can't believe we have nobody else here from rubysigland 19:16:39 here is a list of them all: opennebula, rubygem-addressable, rubygem-data_mapper, rubygem-data_objects, rubygem-dm-aggregates, rubygem-dm-constraints, rubygem-dm-core, rubygem-dm-do-adapter, rubygem-dm-migrations, rubygem-dm-mysql-adapter, rubygem-dm-serializer, rubygem-dm-sqlite-adapter, rubygem-dm-timestamps, rubygem-dm-transactions 19:16:50 https://fedoraproject.org/wiki/Features/Ruby_1.9.3#Scope "Drafts of new packaging guidelines will have to be proposed to FPSCo. No such drafts currently exist. " :-( 19:16:51 spstarr: so i guess if you really want to wait on the ruby sig deciding to *do something* before you push packages, that's your call. 19:17:07 rubygem-dm-types, rubygem-dm-validations, rubygem-do_mysql, rubygem-do_sqlite3, rubygem-extlib - 3rd party being done by someone else 19:17:19 I think you probably want to go ahead and submit and review packages as if we aren't going to update to 1.9.x 19:17:29 rubygem-idn, rubygem-stringex, rubygem-xmlparser 19:17:33 that's all of them 19:17:34 bear in mind that if it's affecting all rubygems, it's probably going to need to be a feature, in addition to going through FPC 19:17:45 abadger1999: that's kind of my thinking 19:17:46 what gets approved now can always be updated to the new guidelines later. 19:18:03 abadger1999: i can do that a lot of these are sub packages of rubygem-dm and rubygem-dm-do 19:18:04 spstarr: since we're pretty much nearly at holiday break here, which means nothing will be getting done for basically a few weeks. 19:18:17 if you're going to wait on them, you'll be hosing yourself. 19:18:24 19:19:05 then I will begin to push these into package review 19:19:07 spstarr: I'd gently poke them asking wtf, though, but I would just go ahead and package as though they're not going to update. 19:19:18 because it's entirely possible that they may not. :) 19:19:38 spstarr: sound good? anything else? 19:19:46 see: https://bugzilla.redhat.com/show_bug.cgi?id=728088 and https://bugzilla.redhat.com/show_bug.cgi?id=588428 for comments in bugs on rubygem packaging 19:19:50 thats all. 19:20:11 spstarr: thanks :) 19:20:16 :) 19:20:20 #topic EC2 19:20:38 gholms: you were mentioning a still-open-occasionally-bothering-people-bug earlier, want to run that by everyone real quicklike? 19:20:48 i know you're double-tag-teaming meetings with gregdek and obino :) 19:20:49 So, I went to delist the F14 EC2 images as we had agreed 19:20:58 jforbes: yes 19:21:13 It seems that they have been deleted, I am guessing dgilmore did it when he was adding the recent F16 images for the new zone 19:21:22 :) 19:21:26 deleted or delisted, or are those the same meaning 19:21:31 is the RNG problem? 19:21:33 Deleted, and not the same meaning 19:21:39 dgilmore: pingy 19:21:48 jforbes: what does that do for people currently using them 19:21:50 * gregdek looks up. 19:21:51 anything? 19:21:56 rbergeron: they are gone 19:21:59 Ah. 19:22:04 rbergeron: pongy amiga 19:22:12 * rbergeron puts a santa hat on gregdek 19:22:23 rbergeron: i deregisted the f14 amis 19:22:30 dgilmore: read up to jforbes' comment re: deleting ec2 images for F14? 19:22:31 rbergeron: currently booted images will continue to function, if they are rebooted they wont come back. that said, delisting them would have the same effect, just a bit harder to undo 19:22:51 dgilmore: we had agreed to not deregister them, only to make them private 19:23:03 jforbes: wasnt communicated to me 19:23:30 dgilmore: I was supposed to do it, but it was discussed in this meeting a couple of weeks ago 19:23:31 * rbergeron notes that maybe we should just make a policy for the process and write it down somewhere so we know for the future 19:23:55 not a huge deal. It just means if we had to back track, they would have other IDs now, which means there is no point at all really 19:24:22 jforbes: there is no point in letting people launch new amis based on a eol release ever 19:24:32 since the os is no longer supported 19:24:36 rbergeron: this will only have to be done again in this way for F15 and F16, policy will change for F17 since we will have a warning mechanism 19:25:29 dgilmore: I'm not sure I agree with this statement 19:25:41 dgilmore: We agreed, but since there was no major communication over that when the images went out, and we have no way of notifying those who are not involved in fedora (casual EC2 users who chose the Fedora image on a whim), we decided that we would make sure we could undo the shutdown and give a migration period if people complained 19:25:48 mgoldmann_: feel free to not agree, but its true 19:25:52 dgilmore: it's not necessarily launching new ones, isn't it also if they have to reboot them as well? 19:26:10 rbergeron: no 19:26:26 rbergeron: if the reboot thier existing instance is still there 19:26:34 dgilmore: It is even worse for F14 because those images were S3 only, so people using them just can't anymore. At least with F15 and F16 they have EBS volumes and can use them until they migrate away 19:26:39 if they shut it down completely and dont save it its gone 19:27:13 dgilmore: there were no EBS images for F15 19:27:16 err F14 19:27:29 dgilmore: yikes. if that happened to me and nobody told me, I'd be *pissed* 19:27:59 johnmark: if you shut a instance down and dont save it its gone 19:28:03 johnmark: thats how ec2 works 19:28:07 For F17 we are going to add a piece to cloud init that checks current supported versions and gives a warning when the image is no longer in a supported state with a reference to the supported images 19:28:36 jforbes: hows that supposed to be communicated to the user? 19:28:53 dgilmore: right, but when I use an AMI, I sort of assume I can always go back to it later. Bad assumption, I know 19:29:23 dgilmore: still working that out, there are a number of options there 19:29:54 okay, so, is there anything we can do *today* or need to do? including: 19:30:04 *update any pages saying F14 is byebye 19:30:11 have we killed off F8? or not really 19:30:36 rbergeron: the fc6 f8 etc images are put up by amazon 19:30:38 rbergeron: there is nothing we can do today, F14 is no longer on the supported ami list 19:30:42 and ive asked them to remove them 19:30:50 oh right 19:31:05 dgilmore: i forgot about that detail 19:31:09 jforbes: okay 19:31:19 i mean can we document it anywhere or that's just htat 19:31:25 rbergeron: this is exactly what it would have looked like had we done it the other way, the only difference is right now we can't backtrack if there is public outcry, we just end up with people with a grudge against Fedora 19:31:44 jforbes: right 19:31:45 okay 19:31:47 so 19:32:03 can we document how we'd like to do this next time, and who and when, so we all know :) 19:32:21 * rbergeron uses the royal we and hates being that guy, since she's not the one doing it 19:32:32 rbergeron: sure, though that was the point of the meeting when we discussed it, it was in the notes 19:33:25 alrighty, well, i can go sift through the notes and add it to rel-eng process somewhere I guess? 19:33:37 or dgilmore can if he's more comfortable noting it himself? 19:33:49 process will change for F17 and later 19:33:55 yup 19:33:59 rbergeron: well im not comfortable doing anything but de-registering unsupported bits 19:34:41 dgilmore: if you make them non public it has the same effect, except that you can undo it if necessary. Keep them registered and private for a period of time 19:34:58 jforbes: but im not comfortable undoing it 19:35:18 there is a reason i am only ok with removing whats not supported 19:35:18 dgilmore: I thought you were in on that discussion, I know jsmith and rbergeron were, as well as a few others 19:35:25 jforbes: i was not 19:35:30 dgilmore: well, releng had nothing to do with F14 or F15 images anyway 19:36:12 jforbes: then i guess i should take down f15 also, so that the only thing from the official fedora account is the official fedora bits 19:37:07 dgilmore: they were approved as official fedora bits when releng couldnt get them done, I can forward you the minutes from the Fedora board meeting on the F15 images 19:37:26 jforbes: approved by whom? 19:37:33 dgilmore: The fedora board 19:37:45 jforbes: id like to see that email 19:38:00 dgilmore: you were in the meeting, but I will be happy to forward it to you 19:38:30 jforbes: anyways im not trying to be difficult. but we shouldnt be allowing people to run things with potential secuity flaws 19:38:46 dgilmore: isn't their choice? 19:39:06 dgilmore: the point was not to enable them to do that, the point was that we have no way to inform them on these older AMIs 19:39:16 and we wanted to at least have a failsafe in case 200 thousand people came screaming at us 19:39:18 mgoldmann_: it is, but we need to do everything to not allow it 19:39:19 we're not forcing them to do this, we say: there you have never version which is supportes and should be used 19:39:21 so we could avoid drama. 19:39:31 that's all 19:39:42 not trying to extend it for them, just... basically a CYA for us 19:39:42 dgilmore: in the end, we agree to that point, the issue was, since we have users who are in no other way involved with Fedora, we wanted an option to be able to back out with severe warning if necessary 19:39:52 dgilmore: it was a fail safe is all, an 19:39:55 because the last thing we want is some horrible public spectacle 19:40:08 I was not part of any meeting talking about this but I would be against removing/making private 19:40:20 it's like: let's remove all ISOs from mirrors 19:40:38 not all - old Fedora versions of course :) 19:40:50 dgilmore: and with other installations, people are more than welcome to continue running after EOL (I still have an F14 box here I haven't upgraded yet, I will do so when I get a chance) 19:41:05 but hey, I'm just a small guy without vote :) 19:41:27 jforbes: people can continue to run existing installations 19:41:41 but they can't reboot them? 19:41:43 dgilmore: these are not EBS images, so not really 19:41:45 A data point: Ubuntu images inform the user of outdatedness with /etc/motd messages. 19:41:59 rbergeron: EC2 is specific, you can reboot 19:42:10 gholms: that was the plan with my changes to cloud init 19:42:58 * rbergeron sighs and moves to round up this topic 19:43:07 I think we're about done here, are we not? 19:43:26 on this topic anyway 19:43:30 * rbergeron shakes her jingle bells 19:43:50 * johnmark looks up 19:44:09 going once, going twice..... 19:44:18 done 19:44:19 #topic Gluster-land 19:44:28 * rbergeron looks at johnmark, jdarcy, kkeithley, not necessarily in that order 19:44:30 ugh 19:44:33 yes 19:44:34 I got nothin' 19:44:37 :) 19:44:38 rbergeron: https://bugzilla.redhat.com/show_bug.cgi?id=747692 19:44:40 kkeithley: HI 19:44:47 this is the link to the EC2 issue 19:45:03 mgoldmann_: i'll come back to it :) 19:45:03 * gholms clicks 19:45:08 gholms: you've seen it 19:45:14 Ah, yes. That bug. 19:46:05 kkeithley: nothin? :) 19:46:12 just EPEL6 builds of gluster and heka are in the fedora updates pipeline 19:46:41 Yay! 19:46:43 if anyone wants to give them some karma love, but not required 19:46:56 kkeithley: ooooh... cool 19:47:08 #info EPEL6 builds of gluster and hekafs are in the fedora updates pipeline, karma is welcomed but not required :) 19:48:14 kkeithley: thank you, sir :) 19:48:19 #topic Back to this EC2 Bug 19:48:22 de nada 19:48:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=747692 19:48:44 So this is a bug that some people have hit, others have not, nobody can figure out how to reproduce. 19:49:21 I think red_alert and verdurin are the ones who hvae. 19:49:24 sounds like a fun 19:49:31 mgoldmann_: yes, i have party hats 19:49:38 If anyone encounters this bug the system and cloud-init logs would be useful. 19:49:38 I personally haven't seen it 19:49:48 So far everyone has posted only console output, which isn't very helpful. 19:50:04 #info if anyone hits this bug the system and cloud-init logs would be useful, so far we only have console output 19:50:26 if this is random, and the source (AMI) is the same I would thing that it relates to the hypervisor somehow 19:50:31 think even! 19:51:03 See the commentary in the bug. If you need help getting the logs off your instance either read the EC2 primer or ask in #fedora-cloud. 19:51:50 #info see bug commentary, if you need help getting logs off your instance either read the EC2 primer or ask in #fedora-cloud 19:52:02 :) thanks gholms, mgoldmann_ ;) 19:52:07 #topic Aeolus 19:52:13 * mgoldmann_ was just rambling 19:52:15 * rbergeron thought she saw an mmorsi wander in here 19:52:30 rbergeron: howdy 19:52:46 came to lurk but lets see 19:52:51 mmorsi: how's aeolus-land going? :) 19:52:57 aeolus is completely in fedora thats one biggie 19:52:59 pretty good 19:52:59 * rbergeron wonders if you know anything about impending ruby-land-changes 19:53:19 more features coming soon, include a much much simpler usage / installation scenario 19:53:29 ah ruby-land 19:53:41 well we're pushing towards ruby 1.9 19:53:49 so be prepared (but hopefully not scared!) 19:54:07 vit has been doing alot of work updating packages to comply w/ that and rspec 2 19:54:07 * gholms crosses his fingers 19:54:18 tho if you maintain a package you might want to try it out against his testing repo 19:54:22 one sec i'll get u a link 19:55:14 mmorsi: there was some discussion earlier about if anyone was going to file changes with the packaging sig and/or file a feature since apparently it's going to require changes in all rubygems? 19:55:27 here ya go http://lists.fedoraproject.org/pipermail/ruby-sig/2011-November/000693.html 19:55:29 * rbergeron wasn't sure if you were regularly attending rubysig meetings 19:55:54 Is this like another mass-rebuild? I'm not sure how stuff works in ruby-land. 19:55:59 hrm not sure, i can ping vit re his thoughts on that and get back to you 19:56:01 gholms: exactly, i'm not sure 19:56:12 mmorsi: spstarr was kind of wondering for packaging opennebla 19:56:21 i'm hoping it won't be too bad, as vit is doing alot of work w/ individual packages 19:56:24 and was expecting packaging changes 19:56:30 and guideline changes perhaps 19:56:31 he's been pinging alot of maintainers individually 19:57:39 ya put an action item down for me for that and i'll get back to you at the next cloud-sig mtg 19:57:55 hrm what else 19:58:21 #action mmorsi to investigate with ruby-sig/vit about (a) changes to packaging guidelines (b) feature filing (c) extent to which rubygems need repackaging/rebuilding/mass rebuilding? 19:58:27 :) 19:58:29 oh of course! how could i forget about snap! which is now in fedora https://admin.fedoraproject.org/pkgdb/acls/name/snap 19:58:39 #info more features coming to aeolus soon, including a simpler usage/installation scenario 19:58:43 so you can yum install snap 19:58:51 and take snapshots of fedora systems on the cloud 19:58:54 #info snap! is now in fedora http://lists.fedoraproject.org/pipermail/ruby-sig/2011-November/000693.html 19:59:01 #info can take snapshots of fedora systems on the cloud 19:59:03 and use those snapshots to migrate those instances to other cloud providers 19:59:05 snapshots as in configuration? 19:59:09 or... ahh 19:59:11 rbergeron: well the idea is 19:59:24 snapshot contains repos + packages + files outside the package system + service data 19:59:41 only files track'd outside the package system are stored so snapshots are lightweight 19:59:47 mmorsi: so... sort of like.. puppet manifest???? am i right there? 19:59:50 and service data is collected using native tooling 20:00:06 sorta, but puppet and chef are used to orchestrate systems from scratch 20:00:13 snap is used to take a snapshot of an existing system 20:00:15 Kernel? Running state? 20:00:21 so you have an instance running on the cloud 20:00:25 you take a snapshot of it 20:00:30 move that snapshot to another cloud 20:00:37 no pre-orchestration needed 20:00:44 gholms: it uses all the native tooling 20:00:52 and has a very simple / pluggable interface 20:01:04 so right now there are plugin for yum and apt-get repos and packages 20:01:14 as well as services such as postgres, mysql, httpd, iis 20:01:19 "The native tooling" is quite a broad term. I will look at the code. :) 20:01:20 oh and windows support as well 20:01:25 #info snapshots contain repos + packages + files outside the package system + service data 20:01:28 https://github.com/movitto/snap 20:01:33 mmorsi: is there a separate ... ah, yes 20:01:38 #link https://github.com/movitto/snap 20:01:46 mmorsi: sounds interesting, thanks for the update :) 20:01:53 gholms: yes i made it as extesnible as possible 20:01:57 no problem 20:02:09 if there are any questions or anything along those lines just ping 20:02:11 I like the idea :) 20:02:14 i've been adding lots of features 20:02:27 working on the ability to migrate snapshots between os's 20:02:34 so you can take a snapshot of an ubuntu instance 20:02:43 and convert it to a snapshot of a fedora instance 20:03:02 YES 20:03:02 (that feature is still being worked on tho, still has a ways togo) 20:03:07 oh wait, did i say that out loud 20:03:09 ;) lol 20:03:13 but i have a proof of concept locally 20:03:16 * mmorsi needs to blog about it 20:03:19 cool :) yes 20:03:19 but oh the time 20:03:25 i have two hackfests for fudcon 20:03:26 you should make it an F17 feature too IMO 20:03:34 one is going to be aeolus, and one is going to be snap 20:03:35 Ah, I thought it was talking to the clouds directly. Good idea to not worry about that. 20:03:44 btw really looking forward to meeting alot of you there 20:03:54 mmorsi: indeed :) do you have your room booked yet? :) 20:03:59 gholms: nope this is a general system snapshotter 20:04:01 rbergeron: ah shoot 20:04:05 so many things going on 20:04:07 forgot about that 20:04:11 mmorsi: get it before it closes off :) 20:04:12 * mmorsi hopes they are not all booked 20:04:14 k 20:04:16 will do today 20:04:30 well 20:04:37 cool :) 20:04:42 #topic Open Floor 20:04:45 not to move along or anything 20:04:52 but I have to eat and other things 20:04:52 haha no worries 20:05:04 mmm food 20:05:13 yeah, nourishment 20:05:41 I'm hungry, no food in fridge, beer just run out 20:05:53 disaster 20:05:57 yikes 20:06:04 If nobody else has anything, i'll close out in a few 20:06:23 * rbergeron notes she is refraining from harassing cloudstack and eucalyptus friends today, in the spirit of the holidays and stuff 20:06:28 mgoldmann_: Time to go out and grab a pizza? 20:07:01 gholms: I haven't had a pizza since a long time, sounds good :) 20:07:08 :D 20:07:21 Thanks, everyone! 20:08:16 PIZZA 20:08:17 mmm 20:08:21 thanks guys. 20:08:24 I think we'll be off next week. 20:08:40 Unless you want to join me for Drunken Cloud SIG Holiday Party online 20:08:51 Dunk Kitchen? 20:08:55 Right. 20:08:55 Drunk* 20:08:57 EXACTLY 20:09:02 i love that girl 20:09:04 yep 20:09:15 #info No meeting next week; Online Cloud SIG Party optional :) 20:09:22 Thanks, folks :) 20:09:24 #endmeeting