21:02:12 <ttx> #startmeeting project
21:02:13 <openstack> Meeting started Tue Dec  3 21:02:12 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:17 <openstack> The meeting name has been set to 'project'
21:02:19 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:02:35 <ttx> #topic Icehouse-1
21:02:48 <ttx> We looked into that during the 1:1s today
21:03:02 <ttx> A few blueprints are still incomplete
21:03:05 <markmcclain> o/
21:03:10 <ttx> The plan is to defer anything that doesn't make it before I cut the branches
21:03:22 <ttx> which should be tomorrow morning Europe time, late night US time.
21:03:36 * ttx checks for recent status changes
21:03:39 * russellb will make a pass through deferring stuff before EOD
21:03:41 <russellb> haven't done it yet
21:03:58 <jgriffith> o/
21:04:02 <SergeyLukjanov> o/
21:05:23 <ttx> markmcclain: how is neutron-tempest-parallel doing ?
21:05:56 <ttx> russellb: recover-stuck-state is completed now ?
21:06:27 <ttx> dims: standalone-rootwrapis not really affected by EOD but could still use a hand at: https://review.openstack.org/#/c/59745/
21:06:43 <stevebaker> o/
21:06:45 <dims> ttx, will look
21:06:49 <ttx> (that's the only oslo blueprint left)
21:07:10 <russellb> ttx: yes, and i just marked it implemented
21:07:19 <ttx> russellb: ok
21:07:38 <ttx> So... any objection to the big deferral plan tomorrow ?
21:08:29 <ttx> I guess that's a no
21:08:40 <hub_cap> heh guess thats a no :)
21:08:45 <hub_cap> lol ttx
21:08:48 <ttx> I'll just wait if a few reviews get stuck in queue
21:09:12 <ttx> but everything missing the necessary approvals will get punted when I reach 3G/wifi
21:09:19 * ttx on a train tomorrow morning
21:09:24 <markwash> ttx: yeah, oslo-messaging for glance is on its way, it might take a little while through the queue
21:09:24 <ttx> #topic Swift 1.11.0
21:09:38 <ttx> So Swift 1.11.0 will be released once the last two blockers (a blueprint and a critical bug) are cleared.
21:09:41 <notmyname> last two patches should merge Real Soon Now (tm)
21:09:44 <ttx> #link https://launchpad.net/swift/+milestone/1.11.0
21:09:54 <ttx> Rough ETA is end of week for the MP branch cut and hopefully mid-nextweek for release
21:10:02 <markmcclain> It will be deferred
21:10:02 <ttx> notmyname: anything you want to add ?
21:10:14 <notmyname> nope
21:10:19 <ttx> markmcclain: ok
21:10:39 <ttx> #topic Icehouse cycle roadmapping
21:10:45 <ttx> #link http://status.openstack.org/release/
21:11:00 <ttx> We have 208 tracked blueprints (completed or >=Medium prio) at this point
21:11:13 <ttx> At this point it should reflect what we expect to land during icehouse
21:11:19 <ttx> ...at least by our current knowledge
21:11:34 <ttx> The trick now is to try to keep it current as we learn more, so try to stay on top of proposed work
21:11:50 <hub_cap> ttx: the i1 for trove is Implemented now (just changed a few min ago)
21:11:52 <ttx> which can be rather tricky as people continue to propose new work all the time
21:12:08 <ttx> hub_cap: ack, trove all set
21:12:26 <ttx> Questions on that roadmapping part ?
21:13:17 <ttx> #topic Red Flag District / Blocked blueprints
21:13:27 <ttx> There are a number of blueprints marked "Blocked"...
21:13:39 <ttx> The idea is to keep that status for blueprints we need to discuss in-meeting, not for stuff that is "normally blocked" waiting for dependent blueprints to be merged
21:13:54 <ttx> (at least not until the absence of progress on dependent blueprints is starting to seriously jeopardize the blocked blueprint)
21:14:08 <ttx> let's see.. we have 5 of them
21:14:19 <ttx> https://blueprints.launchpad.net/heat/+spec/instance-users
21:14:33 <ttx> stevebaker: anything particular you wanted to discuss about that one ?
21:14:44 <stevebaker> ttx: refresh your browser ;)
21:15:00 <ttx> damn, relying on stale release statuys view
21:15:24 <ttx> https://blueprints.launchpad.net/heat/+spec/x-auth-trust then
21:15:36 <hub_cap> i suspect his answer may be the same ;)
21:15:44 <ttx> Well I reloaded that one.
21:15:50 <stevebaker> ttx: that should remain blocked, but possibly priority should be Low
21:15:57 <ttx> and it's still blocked :)
21:16:06 <ttx> stevebaker: what is in blocking on ?
21:16:19 <lifeless> o/
21:16:22 <ttx> keystone/trusts-chained-delegation
21:16:24 <ttx> ?
21:16:49 <stevebaker> ttx: chained-delegation in keystone, which shardy may end up working on anyway
21:17:03 <stevebaker> https://blueprints.launchpad.net/keystone/+spec/trusts-chained-delegation
21:17:38 <stevebaker> yet to be approved
21:17:39 <ttx> stevebaker: ideally we would use another status than "Blocked" if there is nothing to discuss yet to unblock it. "Not started" looks fine by me
21:17:56 <stevebaker> ok
21:18:12 <dolphm> the x-auth-trust bp is new to me... reading that now
21:18:28 <ttx> just set it back to "Blocked" if for example it gets rejected by Keystone or theer is something cross-project to discuss to unblock it
21:18:56 <ttx> david-lyle: you cleared the Blocked status for the Horizon one, cool
21:19:00 <ttx> ones*
21:19:04 <david-lyle> yes
21:19:09 <ttx> Any other blocked work that this meeting could help unblock ?
21:20:05 <ttx> bah, I expect we'll have more as we go deeper in the cycle
21:20:28 <ttx> #topic Incubated projects
21:20:47 <devananda> \o
21:20:52 <ttx> devananda: o/
21:20:58 <ttx> how is ironic going those days ?
21:21:11 <devananda> getting closer
21:21:23 <ttx> anyone from savanna or Marconi ? SergeyLukjanov ?
21:21:42 <ttx> devananda: still targeting i-2 for your first clear milestone ?
21:21:59 <SergeyLukjanov> ttx, everything is ok in savanna - https://launchpad.net/savanna/+milestone/icehouse-1
21:22:10 <SergeyLukjanov> ttx, I'll cut the m-p today
21:22:28 <ttx> SergeyLukjanov: I can do it as I do the others tomorrow, if you want
21:22:44 <devananda> ttx: yes. at the very least, I will want to go through all the milestone & release stuff with you at that point. and I think we are still on target to have soething that (mostly) works by then
21:22:48 <SergeyLukjanov> ttx, good, thanks
21:22:59 <ttx> SergeyLukjanov: will let you know if I run into a problem
21:23:01 <devananda> we might not have some of the less used features of nova-bm, like console support
21:23:20 <devananda> romcheg's work on tempest / devstack integration got blocked for a bit on infra work. i think that's unblocked now.
21:23:21 <SergeyLukjanov> ttx, ok
21:23:45 <ttx> devananda: it's mostly a question of following most of https://wiki.openstack.org/wiki/PTLguide
21:24:41 <ttx> any other question ?
21:24:42 <devananda> ttx: ack. i've read it a few times :)
21:24:55 <devananda> nope
21:25:08 <ttx> SergeyLukjanov: I can run the branch cut just after meeting if you prefer, although I don't want to make you stay up even later
21:25:21 <ttx> #topic Open discussion
21:26:25 <ttx> russellb: was PowerVM removed already ?
21:26:42 <russellb> yes
21:26:46 <ttx> ok
21:26:59 <ttx> anything anyone ?
21:26:59 <SergeyLukjanov> ttx, doesn't matter for me, btw I'll be here for about hour
21:27:15 <ttx> SergeyLukjanov: ok, let's try, looks like meeting will close soon
21:27:28 <notmyname> o/
21:27:36 <SergeyLukjanov> ttx, ok
21:27:40 <ttx> unless someone wants to discuss Critical vs. High for non-deterministic bugs affecting gate again
21:27:40 <russellb> markmcclain: anything we need to sync up on re: neutron vs nova-network?
21:27:45 <ttx> notmyname: go for it
21:28:28 <ttx> markwash: got enough clarity around your client release questions ?
21:28:29 <notmyname> perhaps this should stay on the mailing list for now, but a cross-project issue on the horizon is the "keystone for quotas" issue that was brought up recntly
21:28:44 <markwash> ttx, yeah I can give a little update here I think
21:28:44 <notmyname> I'm fine leaving it on the ML for now
21:28:52 <notmyname> or we can discuss here
21:29:08 <ttx> notmyname: I'm fine with discussing it a bit here. Although I haven't read that thread yet :)
21:29:08 <ayoung> notmyname, that is something that can be done in pieces.  They need an initial implemenation and REST API
21:29:45 * ttx goes to read thread
21:29:48 * russellb isn't up to date on that thread either ...
21:30:03 <notmyname> ttx: tl;dr as I know it is keeping all quota info in keystone
21:30:19 <ayoung> I'd like Quotas to be kind of like KDS:  something that gets incubated in Keystone, but with the potential to move elsewhere.  They are going to need to be able to do an initial population of quota data when the service comes up, or when the first usr hits it, so the REST API has to be first.
21:30:23 <ayoung> Notifications can come later
21:30:26 <ttx> at the very least it's fine to attract our collective attention to threads that should be interesting for us
21:30:39 * russellb wonders what the benefit is?
21:30:51 <ayoung> notmyname, do it as a n extension, like how we implemented KDS, and if we need to push it it a separate service, we can do that over time
21:30:54 <notmyname> ayoung: actually what I'm concerned with is the idea of storing all the quota info in keystone. I don't think that's tennable
21:31:16 <dolphm> i don't see quotas as being a distinct service, at least in keystone
21:31:43 <ayoung> dolphm, right, just the potnetial to split it out as a performance optimization.
21:31:44 <russellb> what's the tl;dr for why this is a good idea?
21:31:45 <dolphm> notmyname: i like the 'flavor' suggestion from the list
21:32:06 <russellb> vs a quota lib
21:32:07 <notmyname> russellb: it's not (IMO) ;-)
21:32:16 <russellb> notmyname: right, got that much, asking from supporters :)
21:32:19 <ttx> notmyname: that's typically the sort of thing that would benefit from being visited in a cross-project session at a design summit
21:32:28 <russellb> indeed
21:32:35 <ttx> because it's so far-reaching
21:32:38 <markwash> notmyname: I share that view.. it seems like quotas tend to need to stored alongside the resource they affect for performance reasons. . I guess some quotas don't fall into that category though maybe
21:32:46 <notmyname> ttx: isn't this meeting the cross-project place to discuss stuff more than twice a year?
21:32:51 <ayoung> ttx, it happened...back in Portland.  We scoped it down to just "static quotas" in Keystone
21:32:58 <ttx> notmyname: it is, it is
21:33:18 <russellb> markwash: yeah, same
21:33:22 <russellb> what are static quotas?
21:33:24 <ttx> notmyname: just thinking out loud... something of this magnitude should have been brought up earlier
21:33:30 <russellb> and why does it make sense for keystone to own them?
21:33:33 <ttx> if it's to appear in this cycle
21:33:39 <russellb> i guess I need to read the thread
21:33:42 <russellb> but count me as a skeptic :)
21:34:01 <ttx> russellb: more than the thread we need to look at the spec
21:34:13 <russellb> i assumed the thread would reference such a thing
21:34:16 <dolphm> russellb: i haven't heard a strong argument for keystone; i agree with ayoung... requirements will likely grow very complex and we'll end up with a quota service in stackforge
21:34:18 <ayoung> static quotas are the limits, not the portion of them that are currrently in use
21:34:33 <dolphm> ayoung: ++
21:34:40 <ayoung> we would not make Keystone the clearing house for "has this user gone over their quote"
21:34:52 <markwash> I think there is a great usecase though for administration / management to have one overall view of quota settings
21:34:56 <russellb> still seems odd
21:34:57 <ttx> ISTR the idea was that some quotas might span multiple projects
21:34:58 <dolphm> it's centralized quota storage, quota distribution via notifications, and decentralized reservations, etc
21:35:30 <russellb> markwash: couldn't you make the same argument for *all* resources owned by a given user/tenant/project/whateverwecallittoday?
21:35:46 <notmyname> any sort of centralized quota storage seems like a bad idea, if it's in keystone or separate
21:35:48 <markwash> russellb: heh, perhaps
21:36:30 <ttx> notmyname: maybe let everyone think about it, and add it for discussion at next week meeting
21:36:30 <ayoung> so I still don't like the notifiation portion of that.  I would rather have the services query it for now.  Question is "at what granularity" and  I think notifications has to address the same question.
21:36:37 <russellb> I think it's the job of some administrative thingy on top of all of these APIs to make that easier to consume and appear together as it makes sense
21:36:46 <dolphm> ttx: not sure i've heard the multi-project quota use case?
21:36:53 <notmyname> ttx: sure. just seemed like something important, especially early in the process
21:37:09 <dolphm> ayoung: why do you want them to query for it?
21:37:18 <notmyname> dolphm: buy 10 VMs and get 10GB free in cinder/swift?
21:37:30 <ttx> notmyname: it is important, and I think it's great to mention the thread here
21:37:31 <ayoung> dolphm, I want them to query for it first, since that API needs to be implemented regardless.
21:37:32 <dolphm> notmyname: lol fair enough
21:37:37 <notmyname> dolphm: but that gets into lots of external integrations
21:37:46 <dolphm> ayoung: oh sure
21:37:50 <ttx> notmyname: just thinking that most of us haven't read the spec so have no good idea about it
21:37:53 <dolphm> ayoung: on startup, HTTP query for it
21:37:59 <dolphm> ayoung: or on first use
21:38:11 <notmyname> ttx: if you add it to the agenda, can you respond to the thread with that info?
21:38:21 <ttx> yes, doing it right now
21:38:26 <dolphm> is this for TC?
21:38:29 <dolphm> or..?
21:38:34 <notmyname> no for in here
21:39:07 <ttx> no, here
21:39:16 <ayoung> dolphm, Notifications have the possibility of being very chatty, as there will be multiple potential consumers, and lots of little notifications that would never really need to be processed.  I suspect taht a query API would serve better over time.
21:39:40 <dolphm> i think it was sandywalsh_ that pushed back on replacing nova's own storage of quotas -- he asked that keystone simply provide updates to nova's existing quota persistence
21:40:01 <notmyname> ayoung: as in a client request would result in a query to keyston/quota_service from the server to see if the quota is full?
21:40:34 <dolphm> ayoung: why would there be a lot of little notifications? i suspect quota changes are relatively rare
21:40:47 <ttx> notmyname: done
21:40:48 <dolphm> especially if you use the 'flavor' concept
21:40:54 <notmyname> ttx: thanks
21:41:02 <ayoung> notmyname, yeah, logic along the lines of the token revocation list:  it will be cached for some period of time, and refreshed.  Notifications could even just be "hey, there is a new one, refresh"
21:41:04 <ttx> Let's read the thread, the spec and discuss more next week
21:41:12 <ttx> markwash: you wanted to summarize the client release thing ?
21:41:14 <markwash> time for a quick mention of the current plan for major client releases?
21:41:18 <markwash> sure
21:41:20 <markwash> There was some discussion a while back about how to stage changes that are part of a major version release of openstack clients. Glance needs this as we'd like to deprecate some crazy old cli stuff and make a few other minor, generally palatable changes.
21:41:22 <notmyname> ayoung: and to be very specific, therefore a client request to a swift cluster would result in the swift cluster asking keystone for the quota usage? that's billions of things to track
21:41:34 <markwash> so the plan that is shaping up now is
21:41:40 <markwash> 1) use a feature branch
21:41:50 <markwash> 2) cut 1.0 once the feature branch is complete
21:42:00 <markwash> at no point would we be supporting both v0 and v1 simultaneously
21:42:14 <markwash> this is still sort of limited in its applicability, i.e. it wouldn't work for truly major changes
21:42:25 <ayoung> notmyname, something has to store it.  I think that Keystone versus some other service is not the real issue, but how to store, update, and query.
21:42:28 <markwash> but I think it gets the job done for us without requiring a lot of changes on the CI side
21:42:41 <mordred> hi!
21:42:56 <markwash> please feel free to tell me how that plan is crazy and I should crawl back into my hole
21:42:56 <ttx> mordred: oh hi!
21:42:56 <mordred> I was just about to send you an email with a plan that's pretty opposite to that :)
21:42:58 <dolphm> mordred had concerns about how that works in testing infra ... i don't remember specifics, but were those resolved by deciding not to support both at once?
21:43:02 <markwash> oh okay cool
21:43:06 <mordred> I have a couple of specific issues
21:43:10 <dolphm> how does tempest "switch" over, etc?
21:43:11 <ttx> making progress here I see
21:43:21 <mordred> one of the main ones being how stable/X deals with teh API change
21:43:38 <markwash> yes, that's a good thing to be concerned about
21:43:47 <mordred> but - srrsly, today has been kicking my ass - let me write up something longform with justifications and details and send it to markwash and the list
21:43:58 <anteaya> russellb: I know markmcclain wanted to talk to you, too bad his connection collapsed. I am meeting with him tomorrow and will draw his attention to your question.
21:44:00 <mordred> I think if I try to vomit it here you'll all just kill me
21:44:21 <markwash> I'm fine with waiting a bit
21:44:31 <mordred> but- tl;dr I think you're going ot have to support v0 and v1 side by side for at least a year
21:44:38 <mordred> because deprecation
21:44:49 * mordred waits to be shot
21:44:50 <russellb> anteaya: yeah we have a hard time connecting
21:44:51 <russellb> busy busy
21:45:04 <anteaya> russellb: nod
21:45:16 * russellb shoots mordred with kindness
21:45:19 <russellb> or something
21:45:20 <mordred> yay!
21:45:29 * mordred gets to take a nap now
21:45:33 <markwash> not a problem for me
21:45:47 <mordred> markwash: but if we can do that - then we can have a 'simple' plan
21:45:58 <mordred> markwash: where we release a 1.0 that also has the 0.x api in it
21:46:10 <mordred> markwash: then bump the min ver on all of our server requirements to >= 1.0
21:46:33 <dolphm> ^ this is what we're planning for keystone, basically
21:46:35 <mordred> then, once the server releases that require less than that are gone, we can release a thing with 0.0 removed, probably called 2.0
21:46:49 <mordred> this is where the libtool version age thing is really nice
21:47:05 <mordred> in that it allows you to specify that you have added na api, but that you support X number of previous apis
21:47:22 <markwash> hmm, interesting
21:47:23 <mordred> it's too bad our friends in semver have not adopted it
21:47:54 <mordred> anywho - lemme write up more details - but I think we can do it without getting ourselves in pretzels
21:47:59 <ttx> ok
21:48:11 <ttx> #action mordred to expose his evil plan on a ML thread
21:48:18 <mordred> oh god. I have an action
21:48:20 <mordred> how did that happen
21:48:33 <ttx> mordred: "lemme write up more details"
21:48:43 <ttx> magic words :)�
21:48:46 <ttx> :) even
21:48:56 * mordred shoots ttx with kindness
21:49:11 <anteaya> looks like you have a cleft in your chin
21:49:31 <ttx> ok, anything else ?
21:50:42 <ttx> I'll take that as a no again
21:50:52 <hub_cap> heh ttx
21:50:55 <hub_cap> just hugs
21:50:56 <ttx> thx everyone
21:50:57 <ttx> #endmeeting