21:02:55 <ttx> #startmeeting
21:02:56 <openstack> Meeting started Tue Feb 28 21:02:55 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:03:02 <ttx> Today's agenda: http://wiki.openstack.org/Meetings/ProjectMeeting
21:03:11 <ttx> #info Today is the last day before we cut the milestone-proposed branches for E4
21:03:19 <ttx> So the last day for E4 late features.
21:03:22 <zns> ziad here
21:03:27 <ttx> #info Targeted bugfixes can still go in once the branch has been cut (until Thursday)
21:03:37 <ttx> Just land them in master and backport them to milestone-proposed
21:03:48 <ttx> #topic Actions from previous meeting
21:03:56 <ttx> * heckj to create BPs corresponding to major feature gaps
21:04:05 <ttx> I saw generate-ec2-access-secret (completed)
21:04:14 <ttx> Was that the only known feature gap ? Are we done ?
21:04:43 <ttx> zns/heckj: ^
21:04:49 <heckj> ttx: I've just sent out an email to the openstack list re: resetting blueprints for keystone
21:05:18 <ttx> not received yet. Business Summary ?
21:06:05 <ttx> heckj: ?
21:07:08 <ttx> Hmm, let's go back to that when he's back
21:07:13 <ttx> #topic Keystone status
21:07:21 <ttx> zns: o/
21:07:27 <ttx> #link https://launchpad.net/keystone/+milestone/essex-4
21:07:38 <ttx> We just mentioned the blueprints, they look all completed
21:07:55 <ttx> zns: any last minute thing expected ?
21:08:05 <ttx> Or are we all set to cut the E4 milestone-proposed branch early tomorrow ?
21:09:11 <ttx> did we lose all the keystone crew ?
21:09:15 <dolphm> everything that needed to go in, is in; there are several more in merge prop that are like-to-haves
21:09:21 <dolphm> ... which should also go in
21:09:42 <anotherjesse> ttx/dolphm: we've been working on an issue jay brought up, but I think it is a simple bug and configuration in devstack
21:10:16 <ttx> in all cases we should be good to cut at the end of the day... please yell if that's not ok
21:10:27 <ttx> No more targeted bugs...
21:10:37 <anotherjesse> ttx: I know we will need a few RCs
21:10:48 <anotherjesse> given that people are just now really pushing the deploys
21:10:48 <ttx> Does that accurately represent what needs to be fixed before E4 can get out ?
21:11:36 <ttx> I guess I should switch to another project until zns or heckj rejoins
21:11:36 <anotherjesse> a few HIGHs are like to haves - like https://bugs.launchpad.net/keystone/+bug/928065
21:11:38 <uvirtbot`> Launchpad bug 928065 in keystone "implement SQL+LDAP backend for Identity" [High,Confirmed]
21:11:48 <anotherjesse> that never existed in keystone legacy
21:12:16 <ttx> anotherjesse: that's definitely a feature... so it would be good to not do it post-E4
21:12:23 <ttx> which means... in the next hours
21:12:24 <anotherjesse> ttx: yeppes
21:12:30 <anotherjesse> ttx: delayed to folsom
21:12:44 * ttx goes to Swift and will be back on Keystone
21:12:50 <ttx> #topic Swift status
21:12:55 <ttx> notmyname: o/
21:12:58 <notmyname> howdy
21:13:03 <ttx> notmyname: 1.4.7 was tentatively scheduled to March 22 -- keep me posted when/if we need to adjust
21:13:12 <notmyname> will do
21:13:41 <ttx> notmyname: Anything on your mind ? Looks like you're the next Swift PTL :)
21:13:42 <notmyname> we've got some merge proposals to get done
21:13:58 <notmyname> several are waiting for a for a final approval
21:14:37 <notmyname> pontificating on PTL stuff, the biggest challenge to swift right now is getting more contributors and building the ecosystem
21:15:00 <ttx> Indeed. Questions on Swift ?
21:15:35 <anotherjesse> same as last week - notmyname can you get someone to review the cli auth review?
21:15:49 <anotherjesse> we have lots of hack in place to special case testing of swift until that lands
21:16:04 <notmyname> anotherjesse: ya, that's one that needs a final approval
21:16:34 <notmyname> we've been fighting some fires around here and havent' had as much time for new code reviews
21:16:37 <ttx> Ouch.
21:16:54 <notmyname> anotherjesse: do you need it before essex? or is that your deadline?
21:17:13 <anotherjesse> notmyname: given that we are testing trunk every day, it costs us time each day to special case swift
21:17:42 <anotherjesse> you've already +2'd - if gholt or someone else could spend 20 minutes to review it would save us so much time
21:17:56 <notmyname> I'll do what I can to get it landed sooner
21:18:18 <notmyname> anotherjesse: I think one of the concerns is the difficulty testing it since none of use use keystone very often
21:18:28 <notmyname> so we can look at the code, but can't actually run it
21:18:42 <soren> ttx: Welcome back.
21:18:42 <jpipes> herro?
21:18:42 <soren> Or?
21:18:43 <notmyname> without a lot more than 20 minutes of work
21:18:51 <ttx> soren: I never left.
21:18:59 <anotherjesse> notmyname: it is compatible with rax global auth
21:18:59 <ttx> and the bot was on my side of the split :)
21:19:06 <heckj> YEAH! back
21:19:08 <ayoung> notmyname, we just had massive IRC failure and missed the start of your statement
21:19:10 <soren> ttx: I have a bunch of people here who'd say otherwise.
21:19:13 <anotherjesse> notmyname: and you can have a complete working setup with devstack
21:19:16 <anotherjesse> netsplit
21:19:23 <ohnoimdead> hooray!
21:19:32 <ttx> ok, let's get back to our regular program
21:19:40 <zns> ttx: a bunch of us were zapped into an alternate IRC universe. We're back now.
21:19:43 <ttx> #topic Keystone status
21:20:09 <heckj> we're in feature freeze, focusing on bugs, docs, and making integration seamless
21:20:15 <notmyname> anotherjesse: I'll bug them about it again, though
21:20:41 <ttx> zns/heckj: blueprints -- all completed, does that mean the feature gap is covered ?
21:20:49 <heckj> I've set "assigned" to empty on all existing keystone blueprints - sent a note to maillist asking if you want to advocate for something in keystone, "assign it" to yourself...
21:21:06 <zns> Copying heckj's response to ttx on blueprints for keystone:
21:21:08 <zns> Gist is - I've cleared "assigned" from all blueprints in keystone. If you want to advocate for a BP, assign it to yourself. Anything unassigned by end of day wednesday will be nuked and we'll start clean. Once that's done, I'll take bugs that should have been blueprints and move them in.
21:21:13 <heckj> Anything unassigned end of wednesday will be burned in purifying flames.
21:21:22 <heckj> zns: thank you
21:21:24 <ttx> zns/heckj: bugs -- no more targeted bugs, Does that accurately represent what needs to be fixed before E4 can get out ?
21:21:35 <ttx> Are we all set to cut the E4 milestone-proposed branch early tomorrow ?
21:21:57 <heckj> ttx: we've one we're still working with jaypipes, dprince, anotherjesse - but we think it's covered. We think we're in good shape
21:22:23 <ttx> heckj: ok, don't forget to target to E4 all bugs that need to be fixed before i'm allowed to release E4
21:22:36 <heckj> ttx: ack
21:22:38 <ttx> #topic Glance status
21:22:43 <jpipes> wheee
21:22:50 <ttx> #link https://launchpad.net/glance/+milestone/essex-4
21:22:54 <ttx> All set featurewise -- can we cut milestone-proposed early tomorrow morning ?
21:23:35 <jpipes> ttx: I'd really like to get this one in: https://review.openstack.org/#change,4350
21:23:51 <jpipes> ttx: but we're having some odd issues with the devstack-vm builder when glance triggers it...
21:24:16 <ttx> jpipes: hmm
21:24:45 <ttx> Looks like a bugfix ? So can be backported to milestone-proposed if not completed by eod ?
21:24:51 <jpipes> sure, yes
21:25:03 <ttx> Looking at the E4 bugs...
21:25:08 <ttx> Looks like a large list, including incomplete bugs...
21:25:13 <ttx> Could you reduce the list to things that should block E4 delivery ?
21:25:28 <ttx> jpipes: and we'll move the rest to a RC1 milestone
21:25:52 <jpipes> ttx: yep, no problem will do as soon as the RC milestone is created.
21:26:08 <ttx> #action ttx to create RC1 milestones
21:26:10 <heckj> ttx: when do you expect to have RC1 milestone created?
21:26:29 <ttx> I'll create them at the end of the meeting
21:26:57 <ttx> (the placeholders in Launchpad, that is)
21:27:05 <jpipes> cool, ty
21:27:18 <ttx> heckj: the idea is to generate the RC when the targeted buglist is empty
21:27:29 <ttx> jpipes: Anything else ?
21:27:34 <heckj> ttx: mkay - thanks
21:27:58 <ttx> heckj: will cc you on the discussion I'm having with E4 PTLs.
21:28:04 <ttx> Questions on Glance ?
21:28:13 <jpipes> ttx: I'd just like to call out eglynn for some great work over the last couple weeks. well done. Same for Stuart McLaren, but he's never on IRC :)
21:28:56 <jpipes> also like to thank anotherjesse, termie, heckj, and dprince for their help today and dtroyer for rockin the devstack. :)
21:29:08 <ttx> cool. Positive vibes
21:29:13 <ttx> #topic Nova status
21:29:19 * jpipes feeling in a thank you mood after Oscars this past Sunday.
21:29:22 <ttx> vishy: survived the split ?
21:29:30 <vishy> yes
21:29:31 <ttx> #link https://launchpad.net/nova/+milestone/essex-4
21:29:38 <ttx> I marked zeromq-rpc-driver deferred, based on last week discussion
21:29:43 <vishy> yes
21:29:44 <ttx> Same for netapp-volume-driver, but it was set back to NeedsReview
21:29:50 <ttx> vishy: What's the situation there ? Both should be deferred and the corresponding reviews blocked ?
21:29:56 <vishy> i think deferred is the only way to go
21:30:03 <ttx> I agree too.
21:30:06 <vishy> I wanted them to get in but I think it is just too late
21:30:17 <ttx> we need to make sure it's clear on those reviews.
21:30:29 <vishy> I need help on targetting bugs
21:30:29 <ttx> vishy: OK to cut E4 milestone-proposed early tomorrow morning ?
21:30:41 <vishy> ttx: there are a few bugs that are critical
21:30:49 <ttx> Let's review them now
21:30:57 <vishy> but they are rc critical, not necessarily e4 critical
21:31:08 <ttx> There are a number of things that are obviously not worked on... and therefore should be un-E4-targeted
21:31:17 <ttx> Not worked on: 914484 (feature parity team), 925665 (Aaron Lee)
21:31:28 <ttx> bug 914484
21:31:28 <uvirtbot`> Launchpad bug 914484 in nova "Boot from ISO is different in XS/KVM" [High,Triaged] https://launchpad.net/bugs/914484
21:31:35 <ttx> bug 925665
21:31:35 <uvirtbot`> Launchpad bug 925665 in nova "virtual_interfaces in nova aren't torn down when under load" [High,Confirmed] https://launchpad.net/bugs/925665
21:31:44 <vishy> yes untarget is fine n the first
21:32:11 <ttx> Unassigned: bug 897075 (anotherjesse/bcwaldon) bug 814469 (bcwaldon) bug 928521 (bcwaldon)
21:32:12 <uvirtbot`> Launchpad bug 897075 in nova "volume int is id not uuid" [Medium,Triaged] https://launchpad.net/bugs/897075
21:32:14 <uvirtbot`> Launchpad bug 814469 in nova "OSAPI reports ACTIVE when server built from bad image" [Wishlist,Confirmed] https://launchpad.net/bugs/814469
21:32:15 <uvirtbot`> Launchpad bug 928521 in nova "If no hosts found during resize, scheduler will leave instance stuck in RESIZE" [High,Confirmed] https://launchpad.net/bugs/928521
21:32:17 <vishy> i don't know about the second
21:32:22 <vishy> pvo: ping on https://bugs.launchpad.net/nova/+bug/925665
21:32:23 <uvirtbot`> Launchpad bug 925665 in nova "virtual_interfaces in nova aren't torn down when under load" [High,Confirmed]
21:32:49 <ttx> dunno about bug 936813 and bug 934464
21:32:50 <uvirtbot`> Launchpad bug 936813 in nova "GET on os-networks/<uuid> fails with quantum" [Medium,In progress] https://launchpad.net/bugs/936813
21:32:50 <vishy> the resize one somenone is working on (littleidea)
21:32:52 <uvirtbot`> Launchpad bug 934464 in nova "New instance imagecache doesn't work with keystone: get_admin_context() doesn't set a valid token/strategy" [Medium,Confirmed] https://launchpad.net/bugs/934464
21:33:11 * littleidea waves
21:33:14 <vishy> i thought that one was fixed
21:33:36 <vishy> the uuid one we can untarget
21:33:44 <vishy> the wishlist we can untarget
21:33:51 <ttx> I'm doing it
21:34:09 <vishy> yeah those last two i don't know about
21:35:03 <vishy> mikal: bug 934464 ? was that fixed?
21:35:03 <uvirtbot`> Launchpad bug 934464 in nova "New instance imagecache doesn't work with keystone: get_admin_context() doesn't set a valid token/strategy" [Medium,Confirmed] https://launchpad.net/bugs/934464
21:35:04 <ttx> There is also a number of critical issues that might make sense being targeted (or have their importance reset):
21:35:12 <ttx> Bug 939060 (tr3buchet)
21:35:12 <uvirtbot`> Launchpad bug 939060 in nova "live migrations do not update dnsmasq entries or setup networking on destination node when using multi_host" [Critical,In progress] https://launchpad.net/bugs/939060
21:35:18 <ttx> Bug 942156 (0x44)
21:35:18 <uvirtbot`> Launchpad bug 942156 in nova "floating-ip-delete disassociates and doesn't de-allocate when ip is associated." [Critical,Triaged] https://launchpad.net/bugs/942156
21:35:21 <vishy> danwent: any idea on bug 936813
21:35:21 <uvirtbot`> Launchpad bug 936813 in nova "GET on os-networks/<uuid> fails with quantum" [Medium,In progress] https://launchpad.net/bugs/936813
21:35:56 <danwent> vishy: will look…
21:36:20 <ttx> vishy: ok to add those 2 to the E4 list ?
21:36:25 <tr3buchet> ttx: i've got a merge prop for 939060, vishy is managing the testing of it
21:36:38 <vishy> yeah i added that critical one
21:37:00 <ttx> ok, both were added
21:37:03 <vishy> ttx: ahead of you, targetted both of those a few minutes ago
21:37:04 <vishy> :)
21:37:06 <ttx> Anything else that should be fixed before E4 hits ?
21:37:13 <ttx> I suggest the following ones:
21:37:17 <ttx> Bug 942443 (comstud)
21:37:19 <uvirtbot`> Launchpad bug 942443 in nova "raise in API when there's no instance_info_cache entry for an instance" [High,Fix committed] https://launchpad.net/bugs/942443
21:37:26 <danwent> vishy:  never seen 936813 before, but oddly enough, we are working on a patch that shoudl fix it for another reason.
21:37:27 <ttx> arh. Fixed.
21:37:30 <vishy> fix committed!
21:37:33 <ttx> Bug 939557 (unassigned)
21:37:34 <uvirtbot`> Launchpad bug 939557 in nova "'nova reboot' under KVM always does a hard reboot" [High,Triaged] https://launchpad.net/bugs/939557
21:37:42 <danwent> vishy: bug 942896
21:37:43 <uvirtbot`> Launchpad bug 942896 in quantum "QuantumManager should set network['host'] when creating the network entry in the database" [High,In progress] https://launchpad.net/bugs/942896
21:37:45 <vishy> I think 939557 i s important
21:37:45 <ttx> Bug 922465 (unassigned)
21:37:45 <uvirtbot`> Launchpad bug 922465 in nova "mismatch between nova project ID and keystone tenant name" [High,Confirmed] https://launchpad.net/bugs/922465
21:37:47 <vishy> lets target it
21:37:53 <ttx> on it
21:37:55 <vishy> I will try and fix it this afternoon
21:38:18 <danwent> bhall is working on 942896, should have a pretty small patch to submit soon.
21:38:40 * ttx reloads the list to see if it looks good now
21:38:56 <vishy> ttx: i don't think 922465 is valid
21:39:03 <vishy> danwent: can we get it today
21:39:17 <ttx> vishy: ok
21:39:25 <vishy> ttx: i think we use project_id == tenant_id everywhere
21:39:27 <danwent> vishy: yes, should be proposed for review within the hour
21:39:42 <ttx> vishy: refreshed https://launchpad.net/nova/+milestone/essex-4
21:39:54 <ttx> bug 942880 is now unassigned ?
21:39:54 <uvirtbot`> Launchpad bug 942880 in nova "Problem specifying device when attaching volumes on XEN" [Critical,Triaged] https://launchpad.net/bugs/942880
21:40:50 <ttx> same for bug 897075 ?
21:40:51 <uvirtbot`> Launchpad bug 897075 in nova "volume int is id not uuid" [Medium,Triaged] https://launchpad.net/bugs/897075
21:41:25 <vishy> i untargeted volume id
21:41:30 <vishy> too big a change at this point
21:41:38 <vishy> we will have to switch to uuids in folsom
21:41:48 <vishy> the other fix is very simple
21:42:03 <vishy> I was just hoping to find renuka to see if there is a reason it isn't supported already
21:42:13 <jdg> vishy: Should I hold off on working on 897075 then?
21:42:13 <vishy> i sent her an email
21:42:26 <vishy> jdg: you can work on it if you want
21:42:27 <ttx> vishy: I'll assign to you, so that you reassign
21:42:36 <jdg> thanks
21:42:45 <ttx> (942880)
21:42:54 <vishy> jdg: just have to wait for merge until folsom
21:43:10 <jdg> NP
21:43:57 <ttx> vishy: ok, the list looks better now -- the idea is to keep it as the E4 blockers, so punting things to RC1 where appropriate to avoid blocking E4 forever
21:44:08 <ttx> vishy: Anything else ?
21:44:21 <rkukura> does bug 941794 need to be targeted in nova to get in for E4?
21:44:22 <uvirtbot`> Launchpad bug 941794 in quantum "VIF and Interface drivers for Quantum Linux Bridge plugin need to be added to linux_net library" [Undecided,In progress] https://launchpad.net/bugs/941794
21:44:40 <ttx> rkukura: starting tomorrow morning yes
21:44:50 <vishy> just a general request to nova core to help review
21:45:01 <vishy> s/review/triage bugs
21:45:05 <vishy> and mark stuff critical
21:45:24 <ttx> Questions on Nova ?
21:45:36 <vishy> There are generally too many to keep up so if anyone sees a bug that looks like it should block release, mark it critical please
21:46:00 <ttx> vishy: hmm, or target it to RC1 (when I'll have that setup)
21:46:30 <ttx> #topic Horizon status
21:46:36 <ttx> devcamcar: o/
21:46:43 <ttx> #link https://launchpad.net/horizon/+milestone/essex-4
21:47:02 <ttx> 5 incomplete blueprints...
21:47:18 <ttx> ohnoimdead: What should hit in the next hours, and what should be deferred to Folsom ?
21:47:46 <pvo> vishy: will peek at that in a sec.
21:48:30 <ohnoimdead> ttx: i think we will have all blueprints done today except ext-roles which is blocked by keystone
21:48:59 <ttx> ohnoimdead: what's your plan for that one ?
21:49:09 <ttx> grant a post-E4 exception ?
21:49:13 <ttx> defer ?
21:49:41 <ohnoimdead> ttx: i think we have to punt on that one sadly.
21:50:17 <ttx> ohnoimdead: ok, so I just cut milestone-proposed with what's in at the end of the day ?
21:50:34 <ttx> or should I wait if anything is not marked Implemented or Deferred ?
21:51:48 <ohnoimdead> ttx: what is "end of the day"?
21:52:05 <ttx> 0900 UTC tomorrow.
21:52:21 <ttx> 11 hours from now
21:52:45 <ohnoimdead> we'll mark everything implemented as we go. i think we'll be good.
21:52:49 <ttx> Looking at the E4-targeted bugs now...
21:53:03 <ttx> I'd like to know which ones are E4 blockers and which ones can be fixed in the weeks that are left until Essex release.
21:53:15 <ttx> The latter can be targeted to RC1 instead.
21:53:32 <ttx> (ince i have that created in a few min)
21:53:38 <ttx> At one point the E4 list must be empty, to signal me that E4 is ready to go.
21:53:49 <ttx> ohnoimdead: does that make sense ?
21:54:20 <ohnoimdead> yeah, makes perfect sense. i don't think anythin on this list is a blocker. just a few nice-to-have cleanups, improvements, etc.
21:54:42 <ttx> ok, so we'll have to punt a few tomorrow to RC1
21:54:49 <ttx> ohnoimdead: Anything else ?
21:54:51 <ohnoimdead> ttx: sounds good
21:54:54 <ttx> Questions for Horizon ?
21:55:09 <ttx> #topic Incubated projects and other Team reports
21:55:11 <ohnoimdead> joe/termie: any comments on https://blueprints.launchpad.net/horizon/+spec/ext-roles?
21:55:31 <anotherjesse> ttx: question on process: we don't do a real release (mark RC as release) until all the RCs are ready - correct?
21:55:46 <anotherjesse> ohnoimdead: not going to land in e4
21:55:59 <termie> ohnoimdead: looks all like stuff you can do on your own by copying policy.py from nova
21:55:59 <ttx> anotherjesse: right. Hopefully on April 5.
21:56:00 <heckj> anotherjesse: ++
21:56:23 <termie> ohnoimdead: but you should probably talk to us more abotu it because you seem to be using global roles
21:56:44 <anotherjesse> ohnoimdead: are you asking can you add arbitrary roles or if there is an RBAC policy api?
21:58:08 * ttx parallelizes
21:58:08 <termie> ohnoimdead: (our general consensus on that was to ahve an "admin" tenant that you grant those roles under, and use that tenant when you are going to perform admin tasks"
21:58:09 <ohnoimdead> termie: cool. you, joe and i can talk offline.
21:58:15 <ttx> danwent, troytoman: yo
21:58:25 <danwent> hi ttx
21:58:28 <troytoman> hello
21:58:32 <danwent> E-4 quantum is looking good: https://launchpad.net/quantum/+milestone/essex-4
21:58:40 <danwent> freezing big features a week early certainly helped
21:58:50 <ttx> danwent: I can cut the milestone-proposed tomorrw morning ?
21:58:59 <ttx> troytoman: same question
21:59:03 <danwent> we have one big fix that needs to go into Quantum, one that will likely need to go into Nova, but we should be good for tomorrow morning
21:59:11 <danwent> both should be easily reviewed today.
21:59:14 <troytoman> ttx: yes. i think we are good
21:59:35 <ttx> danwent: send me an email in the case I shouldn't
21:59:41 <danwent> ttx: ack
21:59:44 <ttx> Any other team lead with a status report ?
22:00:14 <ttx> #topic Open discussion
22:00:30 <ttx> Note that starting tomorrow, in order to assign the last seats, the design summit should no longer be invite-only
22:00:39 <ttx> So if you received an invite and want to attend, you should use it today !
22:00:45 <ttx> Because when we reach max capacity, it will be closed.
22:00:51 <ttx> Also, don't forget to vote :)
22:00:56 <ttx> Anything else, anyone ?
22:01:44 <ttx> ok then
22:01:48 <ttx> #endmeeting