21:02:11 <ttx> #startmeeting
21:02:12 <openstack> Meeting started Tue Aug 23 21:02:11 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:22 <ttx> Welcome to our weekly team meeting... Today's agenda is at:
21:02:26 <ttx> #link http://wiki.openstack.org/Meetings/TeamMeeting
21:02:40 <ttx> #topic Actions from previous meeting
21:02:49 <ttx> * notmyname to double check that everything is included in https://launchpad.net/swift/+milestone/1.4.3
21:02:55 <ttx> In progress ?
21:03:13 <notmyname> done. if anything else comes up, it wll be added
21:03:19 <ttx> cool.
21:03:25 <ttx> * vishy to reprioritize admin-account-actions which is likely to miss diablo
21:03:35 <ttx> We'll talk about that one in the Nova topic
21:03:43 <ttx> * jk0 to push new dep email policy to ML
21:03:52 <ttx> That was done, nobody complained...
21:04:00 <glenc> yet
21:04:08 <ttx> I think for history we should put such decisions on the wiki somewhere
21:04:26 <ttx> so that we can blame newcomers that haven't read it.
21:04:36 <notmyname> dep email policy?
21:04:51 <Vek> change dependencies, send email
21:04:56 <ttx> notmyname: warn about new deps by email
21:04:59 <ttx> to the ML
21:05:17 <ttx> so that downstreams can fix their packaging.
21:05:18 <notmyname> ok :-) just wondering what "deps" was in this context :-)
21:05:28 <ttx> #topic Swift status
21:05:37 <ttx> notmyname: Anything on your mind ?
21:05:48 <notmyname> nothing much to report with the code
21:05:59 <notmyname> I'll be speaking in San Francisco on Sept 8 http://www.meetup.com/openstack/events/30605231/
21:06:46 <ttx> notmyname: that's a crowded week :)
21:07:00 <notmyname> I'm working with mtaylor and jeblair about moving to gerrit. I don't think we have a timeline yet. just "soon"
21:07:08 <ttx> Raise your hand if you have questions on Swift...
21:07:35 <ttx> #topic Glance status
21:07:40 <ttx> jaypipes: o/
21:07:56 <ttx> jaypipes: I'd like to review the missed features and decide between deferring to Essex and granting a post-D4 exception
21:08:18 <ttx> (The idea being to minimize the changes as we get nearer to release. The Essex gates will open on September 8, so it's not that far away for deferred features)
21:08:22 <jaypipes> ttx: SSL support has a branch proposed but I'm stuck on getting a working functional test case for it...
21:08:39 <ttx> what about Add filter for changes-since (changes-since-filter) ?
21:08:42 <jaypipes> ttx: so I'd like that feature to go in.
21:08:48 <jaypipes> ttx: can go to Essex.
21:08:55 <ttx> ok, willdefer
21:09:10 <ttx> jaypipes: You also have 13 D4-targeted bugs, which sounds like a lot to fix in two days.
21:09:25 <ttx> ould you come up with a more reasonable "must-have-for-D4" list and target the others to RBP ?
21:09:30 <ttx> Could*
21:09:48 <ttx> I'd like to know what I should be waiting on, if possible
21:10:08 <jaypipes> ttx: the system-controlled/user-controlled properties will need to go into RBP
21:10:22 <ttx> jaypipes: oh, missed that one
21:10:28 <jaypipes> ttx: and yes on the bugs list. in process of writing a status update to the ML on glance bugs to focus on
21:10:54 <ttx> jaypipes: any eta for system-controlled/user-controlled properties ?
21:12:06 <jaypipes> ttx: depends on when Vek gets the functional test cases done for keystone. He's made good progress with _cerberus_ so far. Expect to see that bug closed soon (https://bugs.launchpad.net/bugs/825419)
21:12:07 <uvirtbot> Launchpad bug 825419 in glance "Functional tests for private and shared images" [High,Confirmed]
21:12:15 <jaypipes> ttx: that bug is the reason for that blueprint being in Blocked.
21:12:37 <ttx> jaypipes: ok. You can add the tests in D4, btw, as a bugfix branch.
21:12:45 <ttx> jaypipes: Other announcements/comments ?
21:13:06 <jaypipes> ttx: thinking...
21:13:09 <_cerberus_> For the record, I *should* have those tests done shortly. Hitting a small roadblock in one of the tests
21:13:27 <jaypipes> ttx: no, I think I'm good.
21:13:31 <jaypipes> _cerberus_: rock.
21:13:53 <ttx> Raise your hand if you have a question on Glance.
21:14:04 <jaypipes> oooh... o/
21:14:11 <jaypipes> annegentle: about Glance API docs....
21:14:37 <jaypipes> annegentle: I'd like to put API doc into the RBP milestone: https://launchpad.net/glance/+milestone/diablo-rbp
21:14:41 <jaypipes> annegentle: OK with you?
21:15:32 <jaypipes> OK, I'll follow up offline on that
21:15:52 <ttx> ok then moving on to the meaty topic
21:15:58 <vishy> pork?
21:16:01 <ttx> #topic Nova status
21:16:02 <vishy> beef?
21:16:06 <vishy> oh, right...
21:16:10 <primeministerp2> veal?
21:16:12 <ttx> vishy: Let's review the numerous features that missed D4 for essex-deferring/rbp-excepting :)
21:16:21 <ttx> * Implement Quantum Network Manager (implement-network-api)
21:16:29 <danwent> hello
21:16:42 <ttx> danwent: This one is proposed for merging, and reasonably self-contained ?
21:17:04 <danwent> pretty much self-contained... a few changes to nova-manage and adding a field to the networks table.
21:17:15 <danwent> otherwise pretty much everything is only run if you run the QuantumManager class
21:17:22 <danwent> which is an alternative to FlatManager, etc.
21:17:22 <ttx> danwent: but depends on Melange stuff, right ?
21:17:41 <danwent> ttx:  i recently change it so that it can work with the nova DB ip address management as well.
21:17:45 <danwent> its a flag
21:18:00 <danwent> by default it uses nova IPAM, flag can change it to use melange.
21:18:16 <danwent> this code needs more testing though... i merge propped it to try and flush out any major concerns early.
21:18:26 <danwent> as wel talked about via email.
21:18:30 <ttx> vishy: sounds like a good candidate for exception ?
21:18:37 <vishy> agreed
21:18:42 <danwent> much appreciated
21:18:46 <ttx> * Adding Volume Types to Nova Volumes (volume-type)
21:19:01 <vishy> i don't think the guys working on that are here atm
21:19:17 <vishy> they have all the db code done and are adding api extensions
21:19:22 <vladimir3p> re volume types : core will be ready today/tomorrow
21:19:27 <vishy> ah there he is
21:19:28 <ttx> vishy: how intrusive is it ?
21:19:38 <annegentle> jaypipes: sorry for the late response, but yes, diablo-rpb seems doable
21:19:38 <vishy> should only affect nova-volume
21:20:15 <ttx> vishy: your call
21:20:24 <vishy> i think it should go in if it can be approved by friday
21:20:37 <ttx> +1
21:20:39 <vishy> if it doesn't make it by friday EOD we have to push to essex
21:20:46 <ttx> * Various requirements for assigning IP addresses to XenServer guests (xs-guest-ip-addressing)
21:21:01 <ttx> This one depends on Melange, and I don't think there is a pressing need to have it in Diablo, or is there ?
21:21:14 <jaypipes> annegentle: k, gotcha
21:21:59 <ttx> tr3buchet: ^ ?
21:22:10 <jaypipes> ttx: the melange merge proposal has a number of things that need fixing IMHO. Might be very difficult to get that in for Diablo...
21:22:33 <vishy> jaypipes: is it the stuff about using the nova version of utils/etc.?
21:22:54 <jaypipes> vishy: well, I had a few more comments than just that on my review :)
21:22:59 <ttx> vishy: I'm with Jay, sounds like a large drop just to be able to show it off
21:23:17 <tr3buchet> ttx: you are correct
21:23:21 <ttx> vishy: I don't expect the packaging to expose it anyway, so what's the point ?
21:23:28 <ttx> * Melange - IP Address Management Service (melange-ipam)
21:23:31 <tr3buchet> ttx: from my end we've got as much of it as we need at the moment
21:23:45 <ttx> ok, jumping to Melange then
21:24:07 <ttx> and deferring xs-guest-ip-addressing to Essex
21:24:14 <vishy> ttx: so can they release an experimental package that is separate?
21:24:26 <vishy> the merge to nova was just to get more eyes on it
21:25:01 <ttx> vishy: I prefer that we don't do that post D4, but rather at the beginning on Essex
21:25:06 <tr3buchet> yeah it's definitely a big work in progress at the moment
21:25:10 <ttx> and get eyes on it in time for the design summit
21:25:37 <ttx> rather than ship half-baked code just for exposing it to the public
21:25:44 <vishy> ttx: i'm ok with that
21:25:50 <ttx> I wouldn't mind so much if it wasn't post D4
21:26:10 <ttx> ok, deferring to essex then
21:26:20 <ttx> * Update Hyper-V to accommodate Diablo changes, add diff disk support (hyper-v-update)
21:26:38 <ttx> sounds like bugfixes to me -- my only gripe is that I couldn't get status from JordanRinke
21:26:49 <ttx> so I don't know where it's at
21:27:02 <primeministerp2> hey guys
21:27:08 <primeministerp2> i'm here
21:27:17 <primeministerp2> i haven't heard from jordan either
21:27:20 <primeministerp2> however
21:27:33 <primeministerp2> just some bits for to add
21:27:44 <primeministerp2> on the hyperv bit
21:27:58 <primeministerp2> we successfully deployed on core
21:28:04 <primeministerp2> er have
21:28:18 <primeministerp2> still have some minor issues to work out w/ networkikng
21:28:32 <ttx> vishy: ok for an exception on this, but would be good to get Jordan's status ?
21:29:10 <vishy> yes
21:29:16 <ttx> * Volume Code cleanup (volume-cleanup)
21:30:06 <ttx> how much of it is cleanup, and how destructive is the cleanup ?
21:30:38 <vishy> ttx: it is separating the concerns of volume and compute
21:30:45 <vishy> so compute talks to volume through the api
21:30:46 <ttx> From the description, it looks a bit risky.
21:30:51 <vishy> and has a plugin
21:31:05 <ttx> as in "prone to introducing some weird bugs"
21:31:32 <vishy> I have gotten it working functionally, I have written some tests for the new code.  It did introduce bugs into live migration, which the live migration team is working on.
21:31:53 <ttx> vishy: why do we want it in Diablo ?
21:32:34 <vishy> ttx: let me think for a sec if there is anything requiring it
21:32:55 <vishy> I think volume-cleanup-1 removing AoE support is important
21:33:00 <vishy> so people don't start using it
21:33:10 <ttx> vishy: is volume-types independent of volume-cleanup ?
21:33:18 <vishy> in theory yes
21:33:30 <vishy> aside from it having to touch the same parts of the code in some places
21:33:48 <vishy> it should be separate
21:34:06 <soren> I think jaypipes had a good point when he suggested that we don't actually know that noone is using it right now.
21:34:30 <vishy> soren: I guess we can't be sure.  But I've never even heard of someone testing AoE
21:34:31 <soren> ...and might be expecting an upgrade path, and failing that, at least some warning before we just break their stuff.
21:34:36 <vishy> let alone deploying it
21:34:41 <soren> Dunno.
21:34:48 <soren> It's an interesting topic though:
21:34:51 <soren> How do we deprecate stuff?
21:34:54 <vishy> soren: how do we notify these people?
21:34:58 <soren> Exactly.
21:35:12 <soren> Even if we decided to keep AoE, but deprecate it, what does that actually mean?
21:35:16 <soren> I mean..
21:35:21 <ttx> soren: sounds like a good topic for the summit. Can you rtm it somewhere ?
21:35:25 <soren> Anyone who's talked to us knows not to use AoE :)
21:35:28 <pvo> vishy: it it printing deprecated notices in the logs when you use it? then pulling next release?
21:35:42 <vishy> pvo: that is what I'm trying to do with auth stuff
21:35:50 <vishy> pvo: so maybe
21:36:02 <soren> ..so it's not like it's a secret that it's de facto deprecated, but we've not really published the deprecation anywhere, and there are no warnings if you choose the AoE driver..
21:36:03 <ttx> vishy: I'm not exactly a fan of this spec. Sounds a good one at the beginning of a cycle, not so much at the end :)
21:36:33 <vishy> ttx: ok.  I'm concerned about leaving bad code in for another 6 months
21:36:50 <vishy> ttx: but you're right it has potential to be destructive
21:37:09 <ttx> vishy:  we all know that Essex will start being better than Diablo about two weeks after Diablo is released
21:37:45 <ttx> so if it gets in to Essex early, it's not really "6 months of bad code"
21:37:57 <vishy> ttx: it is for people building external software
21:37:59 <soren> vishy: We can put in the release notes that AoE is going away.
21:38:03 <soren> Don't use it.
21:38:10 <vishy> soren: seems reasonable
21:38:11 <Daviey> ttx: It's supported for 18 months in Ubuntu.. oh golly.
21:38:35 <ttx> vishy: how about adding deprecation messages in Diablo ?
21:38:36 <primeministerp2> people still use that
21:38:50 <ttx> so that we have a good framework for removing it early Essex ?
21:39:06 <soren> vishy: Don't get me wrong. I want it to *die* *die* *die*, too :)
21:39:32 <vishy> ok, i can put the volume-cleanup code on ice until after the release.  Hopefully merging isn't too painful
21:39:47 <ttx> deal :)
21:39:49 <vishy> I will need to back port a couple of minor fixes that i found while i was working on the code
21:39:55 <ttx> * Virtual Storage Arrays for Nova (nova-virtual-storage-array)
21:40:12 <ttx> this one sounds like a good candidate for deferring, unless I miss something
21:40:23 <vishy> so the main issue with VSA is that it seemed to be a little too tightly coupled
21:40:29 <ttx> as in, still under heavy discussion, and could use another round of design summit
21:40:46 <vishy> I've been working with them to try and separate it out, which was the main motivator for the volume type stuff
21:41:08 <ttx> vishy: a bit late now, right ?
21:41:11 <vishy> but they have put a lot of effort into this branch
21:41:27 <ttx> how self-contained is it ?
21:41:30 <vladimir3p> yep, we are trying to "generalize" it by moving from drive types to volume types
21:41:36 <vladimir3p> and it is pretty self-contained
21:41:38 <ttx> are you confident it can make it very soon ?
21:41:58 <vishy> vladimir3p: did you remove the changes in nova-compute and use instance_types?
21:42:00 <vladimir3p> we can adopt al volume_type changes within next couple of days
21:42:16 <vladimir3p> yep, there are no more changes in nova-compute
21:42:29 <vishy> so if they can switch to using volume-types
21:42:32 <vladimir3p> changes in nova-volume will be minimal and will depend on volume types
21:42:35 <vishy> it will be one additional db table
21:42:53 <vishy> and an additional self-contained worker
21:43:10 <vishy> it would be completely experimental
21:43:26 <ttx> My main issue with this plan is that it needs volume-types to land first
21:43:32 <ttx> so I fear VSA will land *late*
21:43:48 <ttx> (and I hate new features post-D4, too)
21:43:48 <vishy> we could give them the same friday time table?
21:43:55 <vladimir3p> meanwhile we are on track to push it till Thu
21:44:12 <vladimir3p> the VSA merge proposal is in from beg of July
21:44:18 <vishy> vladimir3p: perhaps the best plan would be to just merge the db changes
21:44:22 <ttx> vladimir3p: yes, true
21:44:28 <ttx> ok for Friday
21:44:37 <ttx> * Administrative VMs / containers for provider services (administrative-vms)
21:44:43 <vishy> then it is possible to ship the nova-vsa worker/driver/scheduler separately
21:44:45 <ttx> this one is deferred though, right :)
21:44:54 <vishy> yes defer that one
21:44:59 <vladimir3p> the admin VM we can definitely defer :-)
21:44:59 <vishy> it is still undetermined
21:45:03 <ttx> \o/
21:45:07 <ttx> * Simple Usage (simple-usage)
21:45:15 <ttx> looks very selfcontaine and ready
21:45:58 <ttx> I'd lean towards granting an exception
21:46:17 <vishy> yes just an api extension really
21:46:26 <ttx> * Validation of params in AWS API (aws-api-validation)
21:46:41 <ttx> I'm a bit worried about the state of that one
21:46:48 <ttx> by its own admission it's not really ready
21:46:59 <ttx> though I'd like to see some validation :)
21:47:32 <Daviey> Oo, i didn't know anyone was working on that.
21:47:52 <ttx> It's been longing for you for too long :)
21:48:15 <ttx> vishy: given that it doesn't look ready, I'd defer it ?
21:48:41 <vishy> ttx: It doesn't really seem like a feature to me
21:49:04 <vishy> ttx: it is testing/validation related, so seems like exactly what we should be doing now
21:49:17 <vishy> ttx: or am I misunderstanding the purpose of the next 3-4 weeks
21:49:19 <ttx> vishy: agreed.
21:49:33 <ttx> I was wondering how featureful it was
21:49:46 * Daviey will sniff that branch to see if it does as he expects.
21:49:48 <ttx> but if its client validation, it can't hurt
21:50:02 <ttx> last one:
21:50:04 <vishy> ttx: I think it should be fine to go in without an FF exception.
21:50:04 <ttx> * Admin API: server actions (admin-server-actions)
21:50:15 <vishy> that is thoe one split into 3 parts?
21:50:20 <ttx> vishy: yes
21:50:32 <ttx> that third is the one that is supposedly implemenetd already
21:50:38 <ttx> glenc: is that right ?
21:50:41 <vishy> it didn't seem like they needed an exception for any specific functionality
21:50:42 <glenc> that's correct
21:50:48 <ttx> so is the code in already ?
21:50:54 <glenc> the server (suspend/resume) is already in trunk
21:51:10 <ttx> but not exposed in the API yet ?
21:51:14 <glenc> there's a question as to whether or not it should be implemented as an extension
21:51:19 <glenc> No, it's in the Admin API
21:51:36 <glenc> the question is whether or not it should appear in /extensions since it's not part of the 1.1 spec
21:51:47 <ttx> vishy: what do you think ?
21:52:02 <ttx> if not, then it's completed by D4
21:52:54 <glenc> per jorge w, it should be part of the official admin API spec, but we don't really have that yet
21:53:02 <pvo> it is implemented in the api, used by novaclient, but isn't an extension.
21:53:17 <pvo> official admin api spec? :p
21:53:52 <ttx> we'll take that one offline.
21:53:59 <ttx> The other two parts are planned for end of September, so deferred to Essex.
21:54:02 <vishy> sorry stepped away for a sec
21:54:31 <ttx> vishy: You have two D4-targeted bugs on the list:
21:54:37 <ttx> bug 803654 (availability zone ignored when creating volume) without an assignee
21:54:38 <uvirtbot> Launchpad bug 803654 in nova "availability zone ignored when creating volume" [High,Confirmed] https://launchpad.net/bugs/803654
21:54:41 <ttx> bug 828907 (Distributed Scheduler docs need updating), assigned to dabo
21:54:41 <uvirtbot> Launchpad bug 828907 in nova "Distributed Scheduler docs need updating" [Low,In progress] https://launchpad.net/bugs/828907
21:54:47 <ttx> Anything else that we *need* to fix before D4 release ?
21:54:56 <dabo> ttx: that one's done
21:55:05 <ttx> oh, cool
21:55:10 <vishy> the other can go into rbp
21:55:18 <Daviey> bug 798876 .. i made a start on it, but i haven't been able to finish.. it would be realy nice if we can remove carrot for final release (considering kombu is already required for glance).. would anyone be able to assist?
21:55:19 <uvirtbot> Launchpad bug 798876 in nova "Consider Switching from Carrot to Kombu for AMQP" [Low,Confirmed] https://launchpad.net/bugs/798876
21:55:29 <comstud_> i'm 95% done
21:55:41 <comstud_> been testing code standalone
21:55:46 <comstud_> need to merge it into my branch and fix tests
21:55:55 <comstud_> was out sick all last week, otherwise would be done by now :(
21:56:00 <ttx> vishy: what's your take on that ?
21:56:18 <ttx> (bug 798876 for D4 or for RBP)
21:56:18 <comstud> the problem is that it will introduce a new depdendency
21:56:20 <comstud> for nova
21:56:24 <jaypipes> comstud: picked a bad week to stop sniffing glue.
21:56:30 <comstud> jaypipes: no kidding
21:56:38 <comstud> i can optionally.... make kombu optional
21:56:46 <comstud> and keep the carrot code alongside
21:56:52 <vishy> comstud: it is already a dep
21:56:52 <ttx> comstud: I like that.
21:57:00 <comstud> vishy: for _nova_ ?
21:57:07 <vishy> nova -> glance -> kombu
21:57:10 <comstud> ah
21:57:13 <comstud> i suppose that's true
21:57:20 <Daviey> comstud: I had to use trunk kombu, do you?
21:57:21 <vishy> believe me, it has caused a whole bunch of builds to fail everywhere :)
21:57:30 <Daviey> (which meant amqplib > 1.0.)
21:57:36 <comstud> Daviey: No, I'm working successfully with whatever's in pypi
21:57:50 <comstud> vishy: I believe you :)
21:57:57 <ttx> ok, let's also bring that one offline so that we can rush the end of the meeting
21:58:01 <Daviey> comstud: Yes, sorry that is ~= trunk for what i mean't
21:58:08 <Daviey> it's newer than Ubuntu & Debian.
21:58:12 <vishy> yes online it.
21:58:12 <comstud> ahh yeah
21:58:18 <ttx> #topic Incubated projects news
21:58:26 <vishy> * offline
21:58:27 <ttx> devcamcar, dolphm: you have one line.
21:58:30 <nati> I have more point for bug
21:58:35 <hisaharu> We need to fix bug 828399
21:58:35 <uvirtbot> Launchpad bug 828399 in nova "Can not delete a network which is associated with a project" [Wishlist,In progress] https://launchpad.net/bugs/828399
21:58:42 <danwent> quantum was approved for incubation today :)
21:58:48 <hisaharu> it's almost done
21:59:00 <somik> congratulations quantum team!
21:59:09 <ttx> hisaharu: cool, will add to D4 list
21:59:16 <nati> Thanks a lot
21:59:22 <hisaharu> thanks
21:59:35 <ttx> #topic Design Summit registration
21:59:49 <ttx> As you all should know, we'll have our Design Summit in Boston, from Oct 3 to Oct 5.
21:59:59 <ttx> It is now separate from the OpenStack Conference, which will start on the evening of Oct 5 and end on Oct 7.
22:00:11 <ttx> Registration is now officially open for the Design Summit at: http://summit.openstack.org
22:00:21 <ttx> There is limited room, so register early !
22:00:29 <comstud> FYI, Oct 4 is my birthday.. so I expect gifts.
22:00:35 * comstud hides now.
22:00:37 <ttx> Note that developers attending the Design Summit can get a free pass to attend the OpenStack Conference, if you are interested.
22:00:49 <ttx> Also, this is not for suits. Only for geeks.
22:00:58 <primeministerp2> ttx: question on that
22:01:06 <ttx> primeministerp2: yes ?
22:01:15 <primeministerp2> ttx: I offered to speak re hyperv/openstack
22:01:26 <ttx> primeministerp2: at the conference, right ?
22:01:33 <primeministerp2> yes
22:01:41 <primeministerp2> haven't heard anything else since that
22:01:45 <primeministerp2> I know spector knows
22:01:49 <ttx> primeministerp2: ping spectorclan about it
22:01:56 <primeministerp2> thx
22:01:57 <ttx> #topic Open discussion
22:02:15 <ttx> a bit overtime already. anything else, anyone ?
22:02:16 <annegentle> I'm working on a doc sprint day in Austin, date and location to be determined, but it will be in September.
22:02:35 <annegentle> precise location. Secret bunker. That sort of thing. :)
22:02:55 * ttx watches the registration site crumble under load
22:03:21 <ttx> closing meetingin 10 seconds
22:03:33 <annegentle> I know y'all are jealous of our tying the 86-year record for number of consecutive days with triple digits.
22:03:38 <ttx> #endmeeting