21:02:25 <ttx> #startmeeting project
21:02:26 <openstack> Meeting started Tue Dec 10 21:02:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:29 <openstack> The meeting name has been set to 'project'
21:02:31 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:02:32 <devananda> \o
21:02:42 <ttx> #topic Swift 1.11.0
21:02:53 <ttx> We have a milestone-proposed branch for 1.11.0 set up and if all goes well that should be released on Thursday
21:02:58 <ttx> #link https://launchpad.net/swift/+milestone/1.11.0
21:03:08 <ttx> notmyname: still no issue with it yet ?
21:03:15 <notmyname> nope. things look good
21:03:28 <ttx> notmyname: OK I'll wait for your go-ahead/ping/email to apply tag and upload resulting tarball
21:03:40 <notmyname> ttx: target wed pm or thurs am?
21:04:06 <ttx> notmyname: your call, ideally when we are both awake
21:04:11 <notmyname> ok :-)
21:04:16 <ttx> so your thurs morning / my thursday evening
21:04:37 <ttx> or you ack on thu evening and I get it tagged on Friday morning
21:04:40 <notmyname> sounds good to me
21:05:00 <ttx> notmyname: anything else on that subject ?
21:05:22 <notmyname> I don't have anythingon that for this meeting
21:05:53 <ttx> ok then
21:05:55 <ttx> #topic Icehouse-2
21:06:02 <ttx> We looked into icehouse-2 roadmaps during the 1:1s today
21:06:07 <ttx> Looks mostly in order
21:06:28 <ttx> about 129 tracked blueprints and many many more if you cound Low ones
21:07:08 <ttx> remember icehouse-2 is branched on January 21, tagged on January 23
21:07:22 <ttx> any question on that ?
21:07:41 <russellb> how can we incentivize people to target things realistically, and not just the soonest milestone?
21:07:54 <russellb> a problem i have in nova anyway ... the world is targeted to icehouse-2 right now
21:08:01 <russellb> was i1 before
21:08:23 <ttx> hmm, public shaming when stuff gets deferred ?
21:08:25 <russellb> just something to think about, don't have to go into too deep right now ...
21:08:27 <russellb> heh, perhaps
21:08:28 <ttx> tar and father ?
21:08:32 <ttx> feathers*
21:08:42 <russellb> set their blueprints on fire?
21:08:49 <ttx> frankly, it's a promised delivery date
21:09:04 <ttx> if you constantly say crap, then you lose credibility
21:09:18 <ttx> and your blueprints should lose priority as a result
21:09:21 <markwash> I'm not sure there's always a counterparty to such a promise
21:09:32 <russellb> i guess it's less of an issue for the Low ones
21:09:45 <russellb> but if you get bumped > Low and you miss, it should drop back to Low
21:10:18 <ttx> but yeah suggestions welcome
21:10:22 <russellb> thanks
21:10:25 <russellb> can move on :)
21:10:27 <ttx> #topic Storing quotas in keystone
21:10:37 <ttx> So there was some controversy around a feature proposed for keystone
21:10:45 <ttx> Although not proposed as blueprint for icehouse, nor discussed in a HK summit session afaict
21:10:52 <ttx> notmyname: do you want to try to summarize the concerns ?
21:11:02 <ttx> dolphm: is that thing even on your roadmap ?
21:11:38 <portante> ttx: can you post the feature description link?
21:11:46 <notmyname> IIRC from the email thread, the proposal was to add all quotas into keystone (ie keystone as the authoritative place to store quotas for everything in a system)
21:11:48 <ttx> portante: sure, one sec
21:12:18 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020799.html
21:12:26 <portante> ttx: thanks
21:12:51 <notmyname> ttx: my concern is that I think this is a terrible idea since it makes scaling this store impossible and makes using quota'd systems slow
21:13:12 <chmouel> i think oleg email is more informative http://lists.openstack.org/pipermail/openstack-dev/2013-December/020981.html than mine
21:13:33 <ttx> dolphm: you around ?
21:13:34 <chmouel> notmyname: afaik from the discussion the keystone quota would push out to swift via a notifcation system
21:13:38 <russellb> i don't think it makes any sense, it's not an identity concern
21:13:50 <notmyname> ttx: and I mentioned it last week to ensure it got cross-project eyes on it so that we go in a direction good for the project overall
21:13:52 <dolphm> ttx: sorry, i'm trying to attend two meetings at once :(
21:13:58 <markwash> notmyname: +1 some details have to be denormalized and highly consistent. putting those details (e.g. usage and limit) across service boundaries sounds bad
21:14:01 <ttx> dolphm: bad idea
21:14:09 <ttx> <ttx> dolphm: is that thing even on your roadmap ?
21:14:29 <notmyname> chmouel: and how do you notify changes to 3 million containers?
21:14:36 <dolphm> centralized storage of quotas -- yes
21:14:43 <russellb> on your roadmap?
21:14:50 <russellb> dolphm: did you get support from any other projects on it?
21:15:06 <dolphm> russellb: from the people in whatever session we talked about it in.. about 2 summits ago
21:15:06 <ttx> dolphm: couldn't find a blueprint
21:15:09 <dolphm> it's been slow progress since
21:15:11 <dolphm> ttx: one sec
21:15:15 <chmouel> notmyname: it's by account I was looking at it not for container quota (which is user based in swift)
21:15:27 <ttx> dolphm: at least not a icehouse blueprint :)
21:15:29 <dolphm> https://blueprints.launchpad.net/keystone/+spec/domain-quota-management-and-enforcement
21:15:33 <dolphm> https://blueprints.launchpad.net/keystone/+spec/store-quota-data
21:15:44 <ttx> hah
21:15:45 <russellb> i think clear *current* support from other projects should be a pre-req
21:15:49 <russellb> 2 summits ago is like ancient times
21:15:53 <dolphm> the second one was a direct result of the summit in SF i believe
21:16:00 <dolphm> russellb: ++
21:16:19 <ttx> dolphm: do you agree with notmyname's scalability concerns ?
21:16:28 <chmouel> the etherpad followup in HK  https://etherpad.openstack.org/p/CentralizedQuotas
21:16:44 <dolphm> the direction from the summit was centralized management & peristence of domain- and project-based quotas, but maintain decentralized reservations and enforcement
21:17:08 <russellb> just doesn't seem to make sense why that's centralized, but nothing else is
21:17:31 <russellb> keystone shouldn't be trying to solve openstack-wide administration usability
21:17:42 <ttx> is there a benefit ?
21:18:09 <dolphm> ttx: of course; the suggested answer was that services should pull the latest quotas when necessary, and then subscribe for notifications of updates
21:18:10 <ttx> sounds a bit outside of "identity" to me
21:18:20 <annegentle> how would domain and project quotas map to swift?
21:18:20 <russellb> ttx: +1
21:18:35 <ttx> dolphm: ok
21:18:35 <dolphm> annegentle: domain-based quotas wouldn't, i don't think
21:18:48 <chmouel> but project would do i believe
21:18:52 <annegentle> chmouel: ok
21:19:32 <ttx> dolphm: the way it stands I fear tat there will be quotas in keystone but all the projects would keep their own
21:19:56 <ttx> which makes the benefits of "centralized quotas" (if any), even more dubious
21:20:04 <markwash> I think we just shouldn't confuse central administration with central storage
21:20:08 <notmyname> dolphm: chmouel: they both may and may not map to swift. depends on the implementation of the cluster. identity is decoupled from resources in swift, so can be mapped by whatever application is using them
21:20:40 <ttx> so without buy-in from at least one consuming project there is little point in implementing that in keystone
21:21:16 <ttx> you could even argue that's out of keystone scope
21:21:17 <dolphm> in terms of roadmap in keystone, i see this as purely an extension at the moment, and it's not blocking any other work at the moment, at least in keystone.
21:21:26 <comstud> it feels like centralized quotas will be difficult to keep accurate (in sync)
21:21:34 <comstud> but even if we did them, I don't feel like keystone is the correct place for them
21:21:40 <comstud> IMO
21:21:42 <dolphm> comstud: where would you suggest?
21:21:44 <russellb> dolphm: but who wants to use the extension?
21:21:48 <notmyname> comstud: cache invalidation being a hard problem? :-)
21:21:51 <dolphm> it sounds like a standalone service to me
21:22:04 <notmyname> dolphm: quotas-as-a-service?
21:22:26 <ttx> are decentralized quotas actually bad ? What problem are we trying to solve here ?
21:22:31 <comstud> My current suggestion is keeping them within each project :)
21:22:31 <russellb> quotas-as-a-lib > quotas-as-a-service IMO
21:22:42 <ttx> +1 to both
21:22:44 <comstud> russellb: +2
21:22:45 <hub_cap> quotas lib is necessary
21:22:49 <notmyname> comstud: which AFAIK is where they are now (and working already)
21:22:55 <morganfainberg> russellb, ++, putting on my deployer hat i don't want a quota-service
21:22:55 <russellb> right
21:22:56 <comstud> correct
21:23:26 <notmyname> what is even in a quotas lib?
21:23:29 <morganfainberg> russellb, well a service for the sake of being a service, not that it couldn't exist in something already there.
21:23:44 <russellb> notmyname: just some shared code
21:23:51 <russellb> i think we even have some of it in oslo-incubator right?
21:23:53 <ttx> dolphm: so in summary I feel like this is a feature without a user, so at best a waste of time, at worse an unwarranted keystone scope extension...
21:24:13 <dolphm> ttx: i don't disagree!
21:24:20 <ttx> dolphm: heh
21:24:29 <russellb> yes, quota.py in oslo-incubator
21:24:30 <dolphm> i haven't spent much of my own time on it :P
21:24:57 <russellb> dolphm: so, save us from spending time arguing against it then?
21:24:59 <russellb> :)
21:25:05 <ttx> dolphm: I hope this discussion will give you more grounds to reject the feature if it gets proposed
21:25:16 <russellb> i thought dolphm said earlier it was on the roadmap for icehouse
21:25:33 <dolphm> russellb: if other projects aren't clearly interested, i'll happily push back
21:25:39 <russellb> ok
21:25:41 <dolphm> russellb: it is currently, but it's not blocking
21:25:46 <ttx> https://blueprints.launchpad.net/keystone/+spec/domain-quota-management-and-enforcement is in
21:25:48 <chmouel> dolphm: +1 if no others are interested
21:25:49 <dolphm> russellb: keystone itself isn't the stakeholder
21:25:59 <russellb> who is?
21:26:11 <russellb> honestly this is all about saving you (keystone) some time
21:26:22 <dolphm> russellb: appreciated :)
21:26:26 <russellb> and from ending up with a confusing mixed state of affairs come icehouse
21:26:37 <dolphm> untargeting now
21:26:40 <russellb> ok
21:26:41 <comstud> russellb: just say 'nova is not interested in a centralized quota service' ;)
21:26:50 <ttx> sounds good, moving on ?
21:26:55 <comstud> heheh
21:27:10 <russellb> comstud: well swift started it, i just piled on :-)
21:27:20 <ttx> #topic Red Flag District / Blocked / Interlocked blueprints
21:27:23 <comstud> :)
21:27:32 <ttx> No blocked blueprint afaict
21:27:38 <russellb> yay
21:27:40 <ttx> That said there are a few cross-project dependencies prio mismatch we need to discuss
21:27:48 <ttx> horizon/ceilometer-api-enhancements (Medium, lsmola, icehouse-2) depends on:
21:27:52 <ttx> ceilometer/statistics-order-by-and-limit-for-grouped-query (Undefined, No assignee, next)
21:28:05 <ttx> jd__, david-lyle ?
21:28:16 * jd__ listening
21:28:19 <ttx> If that's a true dep we might need to raise prio/targeting of the Ceilo blueprint
21:28:33 <ttx> if that one doesn't get done maybe the horizon plan should be anadoned
21:28:37 <ttx> abandoned*
21:28:46 <jd__> I can change the prio and target it, but if nobody is assigned to it, it won't be done
21:29:02 <ttx> jd__: no point in targeting it if nobody does it
21:29:12 <jd__> my point (pun intended)
21:29:20 <david-lyle> I think it is a partial dependency
21:29:48 <david-lyle> We may be able to achieve sections of the bp without this particular ceilometer bp
21:30:15 <david-lyle> I'll work with lsmola to resolve if no one picks up the dependency
21:30:19 <ttx> david-lyle: so I'd split the blueprint in two, one part depending and the other not, and target the second part to "next"
21:30:32 <david-lyle> ttx: will do
21:30:43 <ttx> that way the i2 work doesn't depend on something nobody is working on (yet)
21:30:53 <ttx> lsmola said that complex-filter-expressions-in-api-queries might actually solve the requirement though
21:31:11 <ttx> so maybe it's just about replacing the depend to point to that instead
21:31:38 <ttx> OK, the other one is:
21:31:40 <ttx> heat/management-api (High, andersonvom, icehouse-2) depends on:
21:31:46 <ttx> keystone/service-scoped-role-definition (Undefined, arvind-tiwari, No milestone)
21:32:17 <ttx> same thing, if it's a true depend it's unlikely to be doable if the keystone BP itself is not in icehouse
21:32:25 <ttx> stevebaker, dolphm: ?
21:32:51 <stevebaker> dolphm: could this please be evaluated for approval? https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
21:33:27 <stevebaker> dolphm: we have a High icehouse-2 blueprint depending on it, so one way or another the blueprints will need to be aligned
21:33:30 <ttx> stevebaker: ideally Arvind Tiwari would target the appropriate milestone
21:35:15 * ttx reads heat/management-api waiting for dolphm
21:35:24 <ttx> https://blueprints.launchpad.net/heat/+spec/management-api
21:36:23 <ttx> stevebaker: any idea if Arvind is likely to deliver that ? i.e. is it more of a resource assignment problem, or a BP acceptation problem ?
21:37:18 <david-lyle> spoke with Arvind re: this bp, he is working to get the bp accepted
21:37:34 <stevebaker> actually I think it may not be a hard dependency, management-api could move to using service-scoped-roles after it lands
21:37:40 <ttx> david-lyle: you should ask Arvind to set the milestone
21:37:51 <ttx> david-lyle: it won't get on dolph's radar until he does
21:38:12 <david-lyle> ttx: ack
21:38:41 <stevebaker> I'll check with shardy_afk to see how hard the dep is
21:38:56 <ttx> So... Arvind targets milestone, Dolph to review/aprove it, stevebaker to check if the BP could be split between one part depending and the other not depending on that
21:39:16 <ttx> and we'll review the blocker again next week
21:39:32 <ttx> stevebaker: works for you ? Looks like we lost dolphm
21:39:41 <stevebaker> lgtm
21:39:44 <dolphm> ttx: stevebaker: david-lyle: apologies! i'll have to read back later, and follow up
21:39:56 <russellb> dolphm: this meeting is better
21:40:20 <ttx> dolphm: moving on read backlog and let us know if proposed plan looks good
21:40:47 <ttx> #topic Incubated projects
21:40:59 <ttx> who do we have
21:41:16 <devananda> \o
21:41:21 <ttx> SergeyLukjanov ?
21:41:31 <SergeyLukjanov> o/
21:41:34 <ttx> I don't think I see kurt_griffiths
21:41:51 <ttx> So quick release integration status update
21:42:02 <ttx> devananda: Ironic got a tag for icehouse-1
21:42:09 <russellb> nick is currently kgriffs_afk
21:42:20 <devananda> ttx: indeed - thanks!
21:42:21 <ttx> devananda: do you feel you're ready to switch to a milestone-proposed branch and tarball model for i2 ?
21:42:33 <ttx> i.e. will have a usable deliverable by then ?
21:43:00 <ttx> to summarize, the milestone-proposed branch model is:
21:43:19 <devananda> for some definition of "usable deliverable" - yes :)
21:43:31 <ttx> on the Tuesday/Wednesday to create a branch from master pointing to the proposed milestone SHA
21:43:53 <ttx> you can backport stuff to the branch for a couple days if really needed (like the tarball is unusable)
21:44:07 <devananda> but yes, I think we'll have the essential bits working, and I would like to go through the process at i2
21:44:11 <ttx> then on Thursday/Friday I tag the HEAD of milestone-proposed
21:44:28 <devananda> AIUI, we dont need Nova integration at this stage (though there's a chance we'll have that, too)
21:44:31 <ttx> that generates a tarball, which is uploaded on Launchpad milestone page
21:44:35 <ttx> (and signed)
21:44:56 <ttx> devananda: ok, so we'll try the switch for i2
21:45:06 <devananda> yea, all of that ^ would be great to do, so that downstream folks can consume it and start testing / giving us feedback
21:45:18 <ttx> SergeyLukjanov: Savanna did the full MP dance / tarball thing for I1, so you're ready
21:45:26 <ttx> we'll do the same for I2
21:45:31 <SergeyLukjanov> ttx, yup
21:45:43 <ttx> No news from Marconi
21:46:01 * ttx should more formally encourage kgriffs to join us here
21:46:01 <SergeyLukjanov> ttx, and it was done by you, so, the correct process was ensured ;)
21:46:38 <ttx> devananda, SergeyLukjanov: any question on release management integration ?
21:46:53 <SergeyLukjanov> ttx, nope
21:46:55 <devananda> just one, slightly tangential
21:47:06 <devananda> any guidelines on a numbering scheme for client releases? I knkow they're not coordinated...
21:47:33 <markwash> semantic versioning?
21:47:35 <ttx> Most libs do major.minor.patch
21:47:42 <ttx> what markwash said
21:47:47 <devananda> cool. thanks
21:47:51 <ttx> devananda, SergeyLukjanov: how are the other parts of your incubation going so far ?
21:48:07 <ttx> like QA/docs
21:48:10 <devananda> ttx: just had some lengthy discussions with tempest folks about ironic getting in there
21:48:14 <devananda> it's on track
21:48:17 <ttx> ok
21:48:26 <SergeyLukjanov> ttx, the first version of heat integration will be landed soon
21:48:35 <devananda> https://review.openstack.org/#/c/48109/8 and https://review.openstack.org/#/c/53917/8
21:48:50 <ttx> SergeyLukjanov: sounds good
21:48:50 <notmyname> devananda: http://www.python.org/dev/peps/pep-0440/
21:48:53 <devananda> and there's an ML thread on it now, as well. so we should see that land soon
21:48:55 <annegentle> SergeyLukjanov: ttx: I do have an action item to write up some guidelines for writing pluggable docs
21:48:56 <SergeyLukjanov> ttx, first patches for tempest was created to add api tests
21:49:25 <annegentle> that should help incubating projects write docs that are easily placed in our existing titles
21:49:28 <devananda> ttx: as for docs, we auto generate both API and developer docs at this point. and i am planning to start working on deployer docs closer to the end of the cycle
21:49:48 <ttx> SergeyLukjanov, devananda: you might be interested in https://review.openstack.org/#/c/59454/ to see TC requirements for incubation and graduation
21:49:50 <SergeyLukjanov> annegentle, cool
21:50:05 <devananda> annegentle: it would be good for us to talk at some point about adding ironic as we look at applying for graduation
21:50:10 <SergeyLukjanov> ttx, I've already placed some comments and monitoring changes
21:50:15 <devananda> ttx: looked at that when it came up in the TC meeting
21:50:21 <ttx> SergeyLukjanov: ok
21:50:36 <devananda> ttx: i think we will meet nearly all of taht already, except for # of core reviewers (we have 4 today)
21:50:42 <ttx> it's a living document, trying to represent what the TC is likely to apply as rules
21:50:43 <SergeyLukjanov> ttx, as for the docs, we have http://docs.openstack.org/developer/savanna/ with all docs including different guides and api descriptions
21:50:50 <ttx> ok
21:51:12 <annegentle> devananda: yeah, the docs team would prefer to not add a new title this release, but next release, revise the install guide.
21:51:15 <ttx> let's move on to open discussion, feel free to continue to ask questions
21:51:20 <ttx> #topic Open discussion
21:51:24 <annegentle> devananda: so you're on the radar but not this release, if that makes sense
21:51:32 <annegentle> \o
21:51:34 <SergeyLukjanov> ttx, I'd like to return back this month to discuss the more detailed list of requirements for savanna to graduate
21:51:43 <devananda> annegentle: interesting. how does that work - let's assume we graduate, but are not in the docs?
21:52:02 <annegentle> devananda: docs team mission is to document core
21:52:06 <ttx> SergeyLukjanov: raising a thread on the ML about that would be appropriate
21:52:16 <annegentle> devananda: we are so underresourced we have to draw a line, but we want to work with teams
21:52:19 <SergeyLukjanov> ttx, ok
21:52:31 <annegentle> devananda: to get more docs. heat and ceilometer got some docs in, for example
21:52:32 <ttx> SergeyLukjanov: just make sure the TC members are aware of the thread (posting a link to the -dev discussion on the -tc list is ok)
21:52:47 <ttx> PTLs: By popular demand I'll probably switch our 1:1s to a specific (logged) channel, like #openstack-relmgr-office or something
21:52:49 <devananda> annegentle: understood about resource shortage ... any suggestions on what we can do in the absence of having docs in the official docs?
21:52:54 <SergeyLukjanov> ttx, you've answered my next question :)
21:52:58 <ttx> People want to be able to conveniently access 1:1s content, without having to filter noise from #openstack-dev channel logs
21:53:09 <devananda> annegentle: ah. so it's fine for us to contribute docs then?
21:53:13 <ttx> russellb: ^
21:53:18 <russellb> ttx: neat
21:53:43 <annegentle> devananda: we want them to plug in to specific titles we already have. What I'm saying is that for icehouse I'm not sure we have a pluggable model for you...
21:54:05 <annegentle> devananda: probably over explaining, but tripleo won't get much from the doc team during icehouse
21:54:11 <ttx> anything else, anyone ?
21:54:14 <annegentle> me me!
21:54:15 <annegentle> pick me!
21:54:35 * russellb imagines annegentle jumping up and down raising her hand
21:54:36 <ttx> annegentle: this is open discussion, feel free to speak :)
21:54:37 <annegentle> We have four interns starting next week with the GNOME Outreach Program for Women
21:54:39 <annegentle> #link https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch
21:54:46 <russellb> awesome
21:54:54 <ttx> we as in openstack ? or docs ?
21:55:00 <devananda> annegentle: hmm, let's chat a bit after the meeting. i may be able to toss some resource your way, but if there's no where to plug the documentation in, then i'm not sure what to do (besides a wiki page)
21:55:04 <annegentle> Dec. 10 is their start date
21:55:41 <ttx> nice
21:55:47 <russellb> 2 docs 2 horizon looks like?
21:55:47 <annegentle> ttx: details are in that link but there is one for API docs, two working on Horizon, one for Marconi
21:56:00 <russellb> Marconi one sounded like a doc thing i guess?
21:56:01 <annegentle> russellb: yeah the Marconi one is more or less doc but mentored by a marconi dev
21:56:03 <ttx> annegentle: yep, saw that on link
21:56:05 <russellb> cool
21:56:16 <russellb> thanks for coordinating, very cool program.
21:56:18 <annegentle> I need to write a blog post
21:56:23 <annegentle> russellb: thanks!
21:56:42 <annegentle> happy for HP to step in to fund some extras after the first round of funding, that was cool
21:56:59 <annegentle> Rackspace, the OpenStack Foundation, and HP (plus GNOME) are making it all happen
21:57:06 <ttx> any other good news ?
21:57:24 <annegentle> ttx: 15 days until Christmas?
21:57:37 <annegentle> :)
21:57:48 <ttx> true. Hope you've been nice.
21:57:59 <russellb> indeed ... and i'm taking a week off from christmas to new years
21:58:06 <annegentle> always
21:58:16 <russellb> because i have to ... but it should be nice.
21:58:21 <ttx> most people do. It's another "recommended off week"
21:58:28 <russellb> +1
21:58:36 <ttx> ok then, let's wrap up
21:58:40 <ttx> thanks everyone
21:58:41 <stevebaker> I'll be 2 weeks off. its summer here
21:58:43 <russellb> thanks, ttx!
21:58:47 <ttx> #endmeeting