21:02:29 <ttx> #startmeeting
21:02:30 <openstack> Meeting started Tue Dec 20 21:02:29 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:43 <ttx> Welcome everyone to what is probably our last weekly meeting of 2011...
21:02:49 <ttx> Today's agenda: http://wiki.openstack.org/Meetings/TeamMeeting
21:02:58 <ttx> Should be a quick one.
21:03:10 <ttx> #topic Actions from previous meeting
21:03:21 <ttx> * ttx to discuss options for getting a sane list of reviews with CI guys
21:03:39 <ttx> still TODO, sorry about that
21:03:45 <ttx> #action ttx to discuss options for getting a sane list of reviews with CI guys
21:03:51 <ttx> * vishy to properly resurrect public-and-private-dns and target it
21:03:58 <ttx> That was done
21:04:04 <ttx> * ttx to give danwent/troytoman more information on release process
21:04:20 <ttx> That was done -- we also decided that we'll try to get Quantum, and maybe Melange, handled by the release team for E3
21:04:30 <ttx> See more about that later in the meeting.
21:04:38 <ttx> #topic Keystone status
21:04:43 <zns> Three announcements/updates:
21:04:51 <zns> 1. Updated E3 targets:
21:04:51 <zns> irc://irc.freenode.net:6667/#link Keystone E3: https://launchpad.net/keystone/+milestone/essex-3
21:04:59 <zns> 2. Much discussions going on about shared CLI Auth across clients. See http://wiki.openstack.org/CLIAuth. Client consistency will be a focus for E3.
21:05:08 <zns> 3. Much of the focus for Essex remains on stability and operationalization.
21:05:22 <zns> Actually, there were 4.
21:05:25 <zns> 4. We are considering pushing RBAC back to F (not deliver in Essex).
21:05:48 <notmyname> zns: why #4?
21:05:51 <ttx> bcwaldon, notmyname: would that (4) affect you negatively ?
21:06:02 <zns> notmyname: The consideration driving not doing it in Essex is the time needed to get alignment and input from all other projects and teams. So far, this has not been high on peoples list (evidenced by the lack of response to our proposals).
21:06:14 <zns> For thise interested in RBAC, we have the following out there for review:
21:06:14 <zns> 1. There is a blueprint out there: https://blueprints.launchpad.net/keystone/+spec/rbac-keystone
21:06:14 <zns> 2. We have a prototype for the middleware that shows what it would send down to Nova (and other services): see email below with links and highlighted JSON sample response.
21:06:14 <zns> 3. We have the API that Dashboard and other users could use defined here: https://review.openstack.org/#change,1243
21:06:24 <zns> If anyone wants to drive that, feel free.
21:06:37 <bcwaldon> We really want RBAC in Nova in Essex
21:06:43 <bcwaldon> looking at you, anotherjesse
21:06:53 <zns> Quoting anotherjesse:
21:06:54 <zns> here is a progression of growth for RBAC:
21:06:54 <zns> * adding to nova/glance/swift hooks (nova only had it in the ec2 api,
21:06:54 <zns> we need to move the checks to a more core location to check in both
21:06:54 <zns> the ec2 and openstack api)
21:06:54 <zns> * loading static rulesets in services (what we did in nova since the
21:06:55 <zns> first release)
21:06:55 <zns> * sending static rulesets from keystone to services (push vs. pull or ...)
21:06:56 <zns> * CRUD for management of dynamic rules
21:06:57 <ttx> he is not around :)
21:06:57 <zns> and we're considering doing the first two only (so no work in Keystone).
21:07:42 <zns> bcwaldon: I agree qith you BTW, just want to be realistic about what we can get done by Jan 26...
21:07:57 <zns> with
21:07:59 <ttx> zns: could you raise a thread on the mailing-list about that ? At the very minimum it will help getting the information out there... and it may get you some help.
21:08:10 <zns> Sure. Will do.
21:08:28 <ttx> #action zns the raise a thread on the ML about RBAC potentially being deferred to F
21:08:38 <zns> Planning on it actually, which is why I have not moved the BP's out of E3 in launchpad.
21:08:45 <ttx> zns: I see three BPs have unknown status. Does that mean they're just not started ?
21:08:57 <ttx> https://blueprints.launchpad.net/keystone/+spec/keystone-client (dolphm)
21:09:00 <ttx> https://blueprints.launchpad.net/keystone/+spec/keystone-manage2 (dolphm)
21:09:04 <ttx> https://blueprints.launchpad.net/keystone/+spec/keystone-logging (joeheck)
21:09:24 <zns> They might be new. We should probably set them to drafting or discussion.
21:09:42 <ttx> zns: That last one also has no priority. Should I set it to Low ?
21:10:15 <ttx> zns: no, I was talking about the implementation field
21:10:24 <zns> ttx: I just set it to medium. It's an important feature...
21:10:35 <ttx> "Unknown" vs. "Not started" or "Started"
21:10:44 <ttx> or "Good progress" etc.
21:10:53 <zns> I set them to Not Started for now. I'll follow up with assignees/owners.
21:11:02 * ttx doesn't like the unknown. Thx!
21:11:10 <ttx> zns: Anything else ?
21:11:20 <zns> ttx: no. that's it!
21:11:30 <ttx> Questions for Keystone ?
21:12:17 <ttx> zns: i'll mark RBAC "slow progress" to show that it's being questioned.
21:12:27 <zns> OK.
21:12:51 <ttx> #topic Swift status
21:12:56 <ttx> notmyname: o/
21:12:59 <notmyname> hi
21:13:09 <notmyname> I don't think I have anything to report
21:13:19 <Vek> that was swift.
21:13:23 <ttx> Cool. Happy holidays, then.
21:13:40 <notmyname> likewise
21:14:13 <ttx> notmyname: i guess you'll have a better idea of when the next Swift will hit at the beginning of January ?
21:14:30 <ttx> or is there nothing yet justifying it ?
21:14:45 <notmyname> ya. most of our internal dev effort has been around product stuff, so there hasn't been anything compelling in swift itself yet
21:15:02 <ttx> ok
21:15:10 <ttx> Other questions on Swift ?
21:15:35 <ttx> #topic Glance status
21:15:54 <ttx> No Jay.
21:16:12 <ttx> bcwaldon: let's have a quick look at https://launchpad.net/glance/+milestone/essex-3
21:16:15 <bcwaldon> It looks like Jay has targeted all of the Images API v2 blueprints at essex-3
21:16:25 <bcwaldon> but very few of them are assigned
21:16:33 <ttx> yes, and most of them have no assignee... does he plan to do them all ?*
21:16:43 <bcwaldon> so with that in mind, if anybody is interested in helping out with this hefty task, please talk to jaypipes or me
21:17:03 <bcwaldon> We need to get it done BY essex-3, so we will absolutely need help
21:17:03 <ttx> I suspect the status is correct, i.e. most of them are not started ?
21:17:14 <bcwaldon> yes
21:17:57 <ttx> bcwaldon: what is plan B if everything can't get in ?
21:18:07 <ttx> bcwaldon: can it land half-done ?
21:18:12 <bcwaldon> Haven't talked to jaypipes about that, he's been handling most of it on his own
21:18:22 <ttx> or is it a big chunk ?
21:18:24 <bcwaldon> I'd suspect we just ship with a partial implementation in a BETA state
21:18:44 <bcwaldon> I'm not sure if the new architecture is compatibile with the v1 api, so we may just HAVE to get it done
21:19:13 <ttx> bcwaldon: looks like you shouldn't commit on too much on Nova's side, since you may be needed on Glance's side :)
21:19:34 <ttx> Any news of Stuart on https://blueprints.launchpad.net/glance/+spec/multi-process-server ?
21:19:45 <bcwaldon> that was just proposed today, so I'm not worried about anything
21:20:29 <ttx> bcwaldon: oh, code was proposed. cool.
21:20:41 <bcwaldon> ttx: right, can you update the bp status to reflect that
21:20:47 <ttx> yep
21:21:12 <ttx> bcwaldon: Any other remark ?
21:21:28 <bcwaldon> ttx: nope, I just need to catch up with jay at some point regarding this v2 stuff
21:21:57 <ttx> definitely.
21:22:03 <ttx> Questions on Glance ?
21:22:25 <ttx> #topic Nova status
21:22:32 <bcwaldon> vishy asked me to remind everyone that we need to focus on getting all our feature blueprints done in the essex-3 timeframe. After that, we are going to focus on stabilization (bugfixes, testing, etc). We won't be accepting features after January 26th!
21:22:46 <ttx> #link https://launchpad.net/nova/+milestone/essex-3
21:22:53 <bcwaldon> And it looks like everything targeted at essex-3 is assigned
21:22:59 <ttx> yes, status and plan generally look good.
21:23:11 <bcwaldon> the subteam leads have been helping quite a bit with bp triaging
21:23:12 <russellb> so essex 3 will get tagged on jan 26th?
21:23:30 <ttx> russellb: yes -- http://wiki.openstack.org/EssexReleaseSchedule
21:23:56 <russellb> ok, thanks.
21:24:11 <ttx> markwash_ wanted to talk about Trusted computing
21:24:20 <ttx> markwash_: floor is yours...
21:24:45 <markwash_> So, I have been working with fred yang on the trusted computing blueprint issues
21:24:50 * markwash_ starts pasting
21:24:56 <markwash_> context!
21:24:56 <markwash_> https://review.openstack.org/1899
21:24:56 <markwash_> https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools
21:24:58 <markwash_> http://wiki.openstack.org/TrustedComputingPools
21:25:09 <markwash_> basically the trusted computing branch adds a long lived component to nova
21:25:17 <markwash_> the main purpose of this component appears to be to add async and caching on top of the HTTP api they are building for host verification
21:25:42 <markwash_> I have some problems with the implementation and I have been working with Fred Yang to address these issues, but encountering difficulty
21:25:49 <markwash_> and I do not want to act unilaterally if there is no nova-core consensus against the approach in the branch I linked
21:25:56 <markwash_> so I want to ask us to reconsider the blueprint as it stands, and require adjustments to it if there is now consensus against it
21:26:46 <ttx> markwash_: I suspect you won't get enough nova-core quorum in this meeting today to take a decision
21:26:57 <markwash_> yeah, I was afraid of that :-)
21:27:09 <ttx> markwash_: I remeber there was a trusted computing thread on the ML, was that question raised ?
21:27:25 <markmc> markwash_, I'm fine with it in principle, but it needs to be less invasive to the scheduler
21:27:30 <bcwaldon> ttx, markwash_: yep, I know I personally agree with you, and I suspect other members of nova-core will, too
21:27:37 <markwash_> I did not explicitly raise the question of reconsidering the bp
21:27:38 <bcwaldon> markmc: exactly, I think that's the right attitude to have
21:27:44 <markwash_> markmc: totally agree
21:27:48 <markmc> markwash_, I suggested host verification should be included in compute capabilities and flavours can use extra specs to match against it
21:28:18 <markwash_> so since we probably can't kick off that reconsideration here
21:28:27 <markwash_> I guess the action item is just to bring that up explicitly on the ML?
21:28:36 <markmc> it already was :)
21:28:49 <markwash_> oh--okay I think I must have missed that
21:29:01 <markmc> I just mean the thread, in general
21:29:04 <Vek> this is going to be a tough couple of weeks to get any responses, though...
21:29:10 <markmc> I guess my comment on capabilities/extra specs was in gerrit
21:29:19 <markwash_> it is still "approved" on the bp page
21:30:18 * markwash_ yields the floor to any responses :-)
21:30:21 <bcwaldon> markwash_: since there seems to be some discussion to be had, I will temporarily block the bp
21:30:31 <ttx> bcwaldon: +1
21:30:52 <ttx> markwash_: I'd raise the issue on the ML so that nova-core can weigh in
21:31:07 <ttx> My personal view on it is that such feature should be made as lightweight and optional as possible
21:31:26 <ttx> but I'm not nova-core :P
21:31:41 <bcwaldon> ttx: your opinion still matters :)
21:32:18 <Vek> especially when I agree with you :)
21:32:33 <bcwaldon> So the action item is to get a consensus from nova-core then rewrite the blueprint to reflect that decision?
21:32:51 <ttx> yes, I'll action markwash_ on raising the issue on the ML
21:33:00 <markwash_> ttx: thx
21:33:15 <ttx> #action markwash_ to raise the future of Trusted Computing bp on the ML to get nova-core consensus
21:33:31 <ttx> hopefully talking briefly about it here will raise the profile of the thread
21:33:36 <markmc> heh, more like
21:33:40 <ttx> bcwaldon: Anything else ?
21:33:44 <markmc> "markwash_ to raise The Future Of Trusted Computing bp on the ML to get nova-core consensus"
21:33:51 <markmc> much more interesting thread
21:33:56 <ttx> markmc: long time no see
21:34:09 <bcwaldon> No, I'm pretty happy with e3 right now. Just needed to higllight the Jan 26 feature freeze
21:34:14 <ttx> Nova subteam leads: anything you wanted to add ?
21:34:15 <markmc> ttx, yeah, I disappeared for a week
21:34:34 <bcwaldon> As the nova-api subteam lead, I did want to highlight the versioning email I sent to the ML
21:34:48 <bcwaldon> Hopefully silence implies agreement
21:35:06 <ttx> hopefully the Api pundits won't derail it
21:35:16 <bcwaldon> ttx: shh, they might hear you
21:35:30 <ttx> bcwaldon: they only inhabit dark MLs.
21:35:39 <ttx> Questions on Nova ?
21:36:11 <ttx> devcamcar: around ?
21:36:19 <bcwaldon> I can stand in for him, too
21:36:20 <devcamcar> o/
21:36:22 <bcwaldon> damn
21:36:23 <ttx> #topic Horizon status
21:36:33 <ttx> #link https://launchpad.net/horizon/+milestone/essex-3
21:36:38 <ttx> Looks good to me !
21:36:56 <devcamcar> looks good, there are a few bugs that still need to be assigned
21:37:34 <ttx> devcamcar: Anything special you wanted to mention ?
21:38:12 <devcamcar> ttx: nothing special, though I will say we've got a few new contributors recently.  this will be an ambitious milestone for us but we've been making a ton of progress so far in essex
21:38:40 <devcamcar> by the end of essex-3 the vast majority of its visual transformation will be completed
21:39:17 <devcamcar> that's it!
21:39:25 <ttx> Questions for Horizon ?
21:40:33 <ttx> #topic Incubated projects and other Team reports
21:40:44 <ttx> danwent, troytoman: around ?
21:40:47 <danwent> hey
21:40:50 <danwent> https://launchpad.net/quantum/+milestone/essex-3
21:41:13 <danwent> pretty full already.  we're trying to prioritize work that requires changes to the quantum manager in nova, so we have them complete prior to e-4
21:42:00 <danwent> we'll also be working to integrate a new plugin for the ryu openflow controller, so its great to have more people joining the team.
21:42:08 <ttx> danwent: so we'll be trying to move the next milestone under release team management
21:42:25 <ttx> That means getting tarball generation jobs under control. So far the melange-tarball and quantum-tarball jobs are big FAIL
21:42:37 <ttx> we need to get CI's eyes on this
21:43:01 <danwent> Ok, this may be related to bug fix james blair has already pushed for review
21:43:35 <danwent> related to a problem installing in a virtualenv.  is james the right person to be talking to about this?
21:43:40 <ttx> yes
21:44:02 <ttx> danwent: anything else?
21:44:06 <danwent> Ok, great.  should be an easy change then, I just didn't have any background on why the bug was filed.
21:44:10 <danwent> nope, that's it.
21:44:35 <ttx> Any other team lead with a status report ?
21:46:11 <ttx> #topic Open discussion
21:46:24 <ttx> We'll skip next week's meeting, so our next meeting will be on January 3rd, 2012.
21:46:32 <ttx> Anything else, anyone ?
21:47:19 <bcwaldon> Nope. Thanks, ttx!
21:47:28 <Vek> merry christmas!
21:47:51 <markmc> g'night
21:47:52 <ttx> and an happy new year. OpenStack 2011 was pretty awesome, let's make 2012 even better.
21:48:04 <ttx> #endmeeting