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