21:01:05 #startmeeting 21:01:06 Meeting started Tue Mar 1 21:01:05 2011 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:07 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:01:11 Welcome everyone to our weekly team meeting... 21:01:18 Today's long agenda: 21:01:22 #link http://wiki.openstack.org/Meetings 21:01:32 #topic Actions from previous meeting 21:01:40 * dendrobates to set priorities for last nova specs: DONE 21:01:47 * jaypipes to set tentative assignees for Glance specs: DONE 21:01:54 * nova-core to review and approve proposals blocking 2011.1.1: DONE 21:02:06 #topic Current release stage: Development 21:02:19 We have passed the middle of this cycle feature merge window. 21:02:45 BranchMergeProposalFreeze is on March 17. You should have your feature branches proposed before that date. 21:03:13 Questions ? 21:03:46 moving on... 21:03:49 I think this time around, most of the questions have already been answered :) 21:03:52 #topic Cactus Release status 21:03:57 I hope so :) 21:04:12 ttx: what specifically are the BPs that have to do with the compute API, and more importantly, is there any chance they will be in a state to propose merging by that date? 21:04:16 The "current release stage" is just a reminder about the cycle. 21:04:39 jaypipes: westmaas is working that and feels confident as of today 21:05:02 * pvo looking up bps... 21:05:03 pvo: have the BPs or bugs been created for the missing functionality? 21:05:08 pvo: k, thx 21:05:19 jaypipes: no, the current one only addresses a subset. 21:05:39 We can come back to that at the end of the release status 21:05:39 jaypipes: the 'missing' functionality is what I hope we can resolve here... 21:05:43 k 21:05:45 #link http://wiki.openstack.org/releasestatus/ 21:05:57 I think we need a priority adjustment: xs-resize (High) is blocked by xs-migration (Medium), so xs-migration should probably be bumped to High 21:06:04 dendrobates: ? 21:06:22 ttx: could probably reverse those then 21:06:30 that was likely my mistake 21:06:40 pvo: ok, I can fix that. 21:06:40 jaypipes: https://blueprints.launchpad.net/nova/+spec/openstack-api-1-1 21:06:48 ttx: I can do it. 21:06:56 if thats ok 21:06:58 xs-migration looks to be in good shape, though. 21:07:04 Just saying. 21:07:11 #action pvo to readjust prios for xs-resize and xs-migration 21:07:17 soren: true, I think dietz said he was almost done 21:07:20 pvo: ah, ok. sorry, I was referring to bps or bugs that break the gap analysis down.. 21:07:25 On the completion rate, based on the current data: 21:07:30 ttx: will do 21:07:33 jaypipes: haven't seen it yet. 21:07:35 <_cerberus_> Yeah, it's merge propped. Just need to make some of the suggest fixes 21:07:39 <_cerberus_> Could use another reviewer though plz 21:07:43 Essential specs: 21:07:51 Glance: 1 completed, 1 proposed, 2 in progress 21:07:51 pvo: k, understood. didn't know, sorry 21:07:54 Nova: 1 in progress 21:08:04 All on track for release, afaik 21:08:09 High specs: 21:08:13 Glance: 1 proposed, 1 not started 21:08:18 Nova: 1 completed, 6 in progress, 1 blocked, 1 not started 21:08:32 The blocked one (xs-resize) should be unblocked soon, like soren and _cerberus_ said 21:08:47 The "not started" one should be started this week, according to antonym 21:08:56 Other specs: 21:09:02 Glance: 5 completed, 1 in progress, 4 not started 21:09:02 yeah, i'm flipping it now, started on it today 21:09:07 Nova: 3 completed, 5 proposed, 10 started, 6 not started 21:09:10 Swift: 3 not started, 1 deferred 21:09:25 Does anyone want to raise a flag about his (Medium/High/Essential) spec not likely to be completed in time ? 21:10:08 From where I'm staying I doubt we'll have the same scores than with Bexar, which is not necessarily bad 21:10:17 (completion scores) 21:10:32 since we targeted more specs on a shorter "stabilization" cycle :) 21:11:13 no comment, so I'll assume everyone is on track :) 21:11:26 On the Nova stabilization effort: 21:11:36 I have a new launchpadlib script to gather that stat... 21:11:45 Last week we actually had 32 bugs opened and 24 fixes committed 21:11:56 This week we had 37 bugs opened and 29 fixes committed 21:12:02 ttx: image-conversion in Glance. not likely to be completed. 21:12:03 whoot! 21:12:18 jaypipes: noted. 21:12:35 This stabilization(sp?) activity triggers a lot of branch reviews... 21:12:47 I think we should prioritize review of new features branches over bugfix branches. 21:12:50 ttx: very slow going in reviews and getting Swift integrated properly (the Swift driver simply didn't work at all, frankly) is a priority 21:13:18 jaypipes: i'll try to get into glance code and help in reviews 21:13:43 One reason for prioritizing this way is that feature branches take longer to be reviewed and fixed 21:13:54 Another reason is that we want new features in as early as possible 21:13:56 ttx: reviews are fine. it's me getting to fixing the stuff IN the reviews that's an issue this particular week (jury duty and all...) 21:14:10 jaypipes: ok 21:14:15 ttx: On that note, people have been very positive about the review duty thing. I think we'll be able to get reviews done quicker very soon. 21:14:17 Last reason is that FeatureFreeze hits first 21:14:26 let's hope so. 21:14:38 ttx: One guy even said he'd give me $700,000,000.00 if I just sent him a bit of money. 21:14:49 o/ 21:14:55 ttx: Or maybe that was about something else... 21:14:59 soren: og! *that* guy. 21:15:24 next, johnpur wanted to get some extra status on specific features he called out in http://www.openstack.org/blog/2011/02/the-openstack-bexar-release/ 21:15:39 "Support for VMware ESX & ESXi hypervisors" 21:15:55 That would be hypervisor-vmware-vsphere-support (Medium, Started). Lots of code was pushed in the last two hours. Anyone from Citrix with more status ? 21:16:30 ewanmellor, maybe ? 21:17:00 "Support for Linux container virtualization through support for OpenVZ and LXC (Linux Containers)" 21:17:17 That's bexar-nova-containers (Low, branch proposed for merging), but it is LXC-only. zul, any additional comment ? 21:17:32 zul: He posted a branch for review yesterday. 21:17:37 Err... 21:17:44 ttx: He posted a branch for review yesterday. 21:17:58 It looks decent. 21:18:00 soren, ttx: i haven't gotten his branch working yet 21:18:10 (on maverick) 21:18:22 that might be a bit tricky. 21:18:28 anyway, on track. 21:18:34 "Additional disk and appliance formats supported in Glance" 21:18:49 I think that's api-image-format (Essential, branch was proposed for merging), jaypipes ? 21:19:25 ttx: correct, it's in review. 21:19:27 "Disk and appliance format conversion support in Glance" 21:19:47 ttx: that will NOT be done...or at least it would be a miracle at this point. 21:19:48 That would be image-file-conversion. In jeopardy 21:20:22 jaypipes: ack, we'll mark it defer when it's abandoned, then 21:20:25 "Live migration of instances" 21:20:36 ttx: We are peer reviewing vsphere-support internally at the moment. 21:20:37 That's cactus-migration-live (Medium, branch was proposed for merging) 21:20:51 ewanmellor: thanks for the update ! 21:21:00 "Features and operational elements availability via XenAPI by Rackspace in preparation for large scale deployment" 21:21:16 ttx: live-migration is in review, but could use a ping of masumotok 21:21:21 I think that's all the xs-* blueprints. We have 2 already implemented, 1 proposed for merging, 3 i nprogress, 1 blocked (soon to be unblocked) and 3 not started yet. pvo, comments ? 21:21:25 ttx: It's being done on Launchpad, so people can look if they want. We intend to bring it to nova-core for review in a week. 21:22:32 ttx: did you count multi-nic (it doesn't have the xs_ prefix). it's currently in progress as well 21:23:00 tr3buchet: no... I tried to split the ozone specs between what was XenAPI specific and what was not 21:23:11 to match the description 21:23:51 I'll remember that I should count multi-nic in 21:23:58 "Performance and scaling improvements in Swift" 21:24:17 That's all the swift specs. One was started but abandoned (using sqlite WAL proved not mature yet), the others are not started yet. Maybe creiht has more details... 21:24:59 "Internationalization and localization in Swift" 21:25:08 No spec was filed for cactus in that area. 21:25:21 johnpur: did you get what you wanted out of this ? 21:25:24 ttx: the performance iprovements continue 21:25:33 there is another branch for proxy pref 21:25:37 yes, thanks for the updates, everyone. Looks good. 21:25:38 currently in merge prop 21:25:54 i18n was mostly done in bexar 21:26:08 All that should be left is hooking up the lp stuff 21:26:27 sorry... today has been a busy day 21:26:34 creiht: should we retrospectively track proxy pref in a blueprint ? 21:26:41 or is it a minor thing ? 21:27:24 I was thought there was a blueprint for it 21:27:49 creiht: we'll sync off-meeting 21:27:50 https://blueprints.launchpad.net/swift/+spec/cactus-asynchronous-proxy 21:28:03 oh, that's the one. Wasn't marked started 21:28:05 ok, you'll async off-meeting, then. ;) 21:28:11 hehe 21:28:25 ok, moving on, long agenda today 21:28:29 ttx: like I said, we've been busy, so i's may not be dotted ;) 21:28:47 I should have caught it by looking at branch names :) 21:29:02 #topic Nova 2011.1.1 release status 21:29:13 I sent an email to the list on Friday, we have a candidate tarball up. 21:29:26 Not sure if anyone spent time testing it... 21:29:39 I did validate that the included fixes do indeed fix the corresponding bugs, except bug 716427 21:29:40 Launchpad bug 716427 in nova/bexar "RPC concurrency problem" [High,Fix committed] https://launchpad.net/bugs/716427 21:29:49 soren: any success validating this fix ? 21:30:02 I also did minimal testing for weird regressions. 21:30:25 i did a few quick spot checks and it appears to have the items it was missing before 21:30:31 ttx: Sorry, no. 21:30:47 soren: missing time ? 21:30:51 ttx: It shouldn't be hard at all, really. 21:30:53 ttx: Yeah. 21:30:57 ok 21:31:00 Now we need to decide to release it or wait for more testing. 21:31:15 I can wait for soren last validation and ship it 21:31:21 Opinions ? 21:31:44 I think we should test it 21:31:50 I volunteer 21:32:01 ttx: +1 21:32:24 My personal opinion is that the fixes are safe, but if we have a few more volunteers, we can wait until Thursday, for example 21:32:51 it's up to you. I am willing to spend a couple days testing it if you need me to. 21:33:02 I'm ok with Thursday. 21:33:14 If no regression is reported by then, we'll ship it 21:33:22 wfm 21:33:28 Remember you compare with Bexar, not cactus 21:33:59 Given all the bugfix work that has been going on in cactus, it's quite a bit better at this point. 21:34:05 As soren could confirm :) 21:34:29 Gawd, yes. 21:34:48 #info Nova 2011.1.1 will be release Thursday, unless a regression against Bexar is reported 21:34:54 released* 21:35:12 #topic python-novatools short term needs 21:35:21 sandywalsh_: floor is yours 21:36:24 ..chirp chirp chirp.. 21:36:41 ok, well, I guess if anyone has any comments? 21:36:45 :) 21:36:51 3 key issues 21:37:03 1. forking from jacobian's original 21:37:09 thoughts? 21:37:18 1+ 21:37:19 sandywalsh_: go fot it :) 21:37:33 sandywalsh_: i can certainly put up an Ubuntu package from your latest 21:37:40 great 21:37:40 Addresses my concerns. 21:37:47 which brings up #2 21:37:58 2. moving novatools into nova or leaving as ext lib 21:38:04 I vote ext lib 21:38:09 +1 external 21:38:09 +1 for ext 21:38:11 <_cerberus_> Me too 21:38:49 I like the idea of putting it in lp:nova/clients/python, but don't care that much 21:38:51 any opposed? 21:39:13 no response from ben right? 21:39:15 especially since it's a dependency for nova (zone communication) 21:39:17 eday, as do I, but it's a little klunky with the packaging when I messed with it 21:39:29 something we might revisit later I think 21:39:39 also lots of changes coming with OS API 1.1+ 21:39:50 sandywalsh_: how so? pakcaging it can just live independently in it's own client dir, no? 21:40:17 eday, yup, just more work to do and not really the time for cactus 21:40:51 mv novatools nova/clients/python && add/commit, no? 21:41:31 eday: what's the benefit of having it in the same code base ? 21:41:34 I'll look at it again, but I thought there were some issues with the shell 21:41:49 txx: less dpeendnecy tracking for devs, less packages 21:42:22 I'll have a look tonight ... if it's clean any opposed? 21:42:39 dabo, jk0 voted external 21:42:50 s/packages/repos 21:42:55 <_cerberus_> ttx: as did I 21:43:10 k, sounds like external for now. revisit later 21:43:11 _cerberus_: yes, but you encrypted your +1. 21:43:16 <_cerberus_> haha 21:43:19 last point: 3. naming. Currently: package=python-novatools, cmdline=nova 21:43:23 like I said, don't really care.. easy to switch later 21:43:48 naming votes? 21:44:10 since it's a direct interface with nova, i think nova is fine 21:44:31 going 21:44:37 going 21:44:42 I like the idea of switching to python-nova, and keeping cmd nova 21:45:07 for consistency if anything 21:45:23 jk0, what would the import be? 21:45:30 import nova.client? 21:45:36 Nova is called python-nova in Ubuntu. 21:45:41 ah 21:45:46 right now it's 'import novatools' 21:45:55 well, I think we could some up wiht something better than novatools 21:45:58 nova = novatools.Openstack() 21:46:00 it doesn't feel right 21:46:27 I don't have anything to propose though 21:46:31 :) 21:46:44 gone? 21:46:46 nova.client would be pretty natural, but that would imply putting it in lp:nova/client 21:47:27 <_cerberus_> Wouldn't most names /nova*/ imply putting it under the same project? 21:47:36 i tend to agree with nova.client 21:48:06 BTW, NovaTools is the name of a resedit plugin. 21:48:27 how about python-novaclient? 21:48:57 why does it have to have python in the front? 21:49:01 there are two parts: the cmdline tool and the client, but that should be ok 21:49:08 (curious) 21:49:22 tr3buchet, ruby-novaclient 21:49:37 (thinking out loud) 21:49:45 that sounds more like a packaging name 21:49:49 ubuntu std naming scheme. 21:49:51 so this is commandline + import library? 21:49:58 yes 21:50:03 the tool is not the same name as the package 21:50:22 so couldn't we name the commandline tool separately from the libs for ruby python etc.. 21:50:28 dabo, right, but one uses the other and setup.py installs both. 21:51:07 I think we should call it "monty" 21:51:15 Then the package would be python-monty 21:51:32 There can only be one monty. 21:52:15 so, there seems to be issues with all names. Which name has the fewest issues? :) 21:53:10 I guess I missed the objection to python-novatools / nova 21:53:11 leave it as is for now. If someone comes up with a better name, we'll consider that then 21:53:22 I like python-novaclient / nova 21:53:33 or even python-novalib 21:53:46 hmm, it's more than just a lib 21:54:01 I could go with novaclient 21:54:16 I like novaclient, sounds like a better description 21:54:18 #agree 21:54:19 vote: python-novaclient vs. existing python-novatools 21:54:38 python-novaclient 21:54:41 +1 for python-novaclient 21:54:44 <_cerberus_> +1 former 21:54:53 when using a CLI tool, who cares if it's Python or Ruby or Perl under the hood. For modules, you may need the language name in the package, but it would be silly as the module name 21:55:16 +1 python-novaclient 21:55:19 it's not the module name. The module name is novatools/novaclient 21:55:51 k, novaclient it is then? 21:55:56 package name python-novaclient, module name: novaclient, cmdline tool: nova. 21:56:05 ttx, yes 21:56:11 The bikeshed is now officially blue. 21:56:16 and I'm done 21:56:24 ttx bang your gavel 21:56:25 let's switch topics, quick 21:56:30 #topic Open discussion 21:56:40 anything else, anyone ? 21:56:50 OpenStack Design Summit Registration Should be up later this week 21:57:00 working on final changes to site right now... 21:57:18 spectorclan: that's for both the conference and the design summit, right 21:57:28 Correct. Just 1 registration for both events 21:57:48 spectorclan: btw, noticed that http://openstack.org/projects/compute/ released date is incorrect 21:58:04 antonym: Hmmm, let me look 21:58:08 on swift as well 21:58:14 spectorclan: what is the status on the summit after diablo? do we know where we are targeting? 21:58:23 2010 is so last year. 21:58:30 hehe 21:58:39 johnpur, working on it but nothing definite yet 21:58:58 ok, there was some question about this earlier 21:59:12 yes, we are moving away from Japan for a formal event 21:59:47 jaypipes: I kinda skipped your question on a missing spec to cover for gaps in openstack api 21:59:54 spectorclan: thx 22:00:23 jaypipes: the current spec only covers some gaps, as far as I can tell. 22:00:46 jaypipes: we don't have a spec filed about doing a full gap analysis and cover that. 22:01:29 time to close the meeting... 22:02:06 #endmeeting