21:03:18 <ttx> #startmeeting project
21:03:19 <openstack> Meeting started Tue Jul 15 21:03:18 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:22 <openstack> The meeting name has been set to 'project'
21:03:23 <ttx> Agenda for today is available at:
21:03:27 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:03:32 <jgriffith> o/
21:03:42 <ttx> #topic News from the 1:1 sync points
21:03:48 <ttx> We had 1:1 syncs today, here is the log:
21:03:52 <ttx> http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-07-15-09.01.html
21:03:58 <ttx> Not much there
21:04:09 <ttx> Key announcement was that russellb would handle juno-2 tagging, so he'll be in touch with you all next week
21:04:17 <david-lyle> o/
21:04:18 <ttx> Most projects look a bit late -- loads of stuff in review
21:04:21 <mikal> russellb: in IRC? or email?
21:04:32 <russellb> mikal: either.  for us, maybe email is better?
21:04:42 <ttx> SergeyLukjanov: you wanted to mention progres on sahara horizon integration ?
21:04:42 <mikal> russellb: sure, whatever works
21:04:49 <ttx> +s
21:04:53 <russellb> just need everyone's help to clear out the j2 pages next week, aim to do it by tuesday or wednesday
21:05:05 <ttx> my advice would be to land what you can ASAP since gate load is likely to go up on Monday/Tuesday next week
21:05:09 <devananda> russellb: tagging incubated projects too?
21:05:19 <russellb> devananda: yes
21:05:22 <devananda> ack
21:05:27 <zaneb> russellb: I'll be out Monday & Tuesday, so I'll find someone to co-ordinate with you on those days
21:05:32 <russellb> though i won't block anything if they're not ready
21:05:37 <SergeyLukjanov> there is a good progress on merging sahara-dashboard to horizon, thanks for david-lyle for bumping prio
21:05:39 <russellb> zaneb: OK, just let me know who
21:05:48 <devananda> ironic is a bit behind -- we just landed specs for several features targeted to j2 (most of the code was written in parallel)
21:05:49 <mestery> russellb: ++
21:06:00 <dolphm> i also wanted to make everyone aware of this bug: https://bugs.launchpad.net/nova/+bug/1342274
21:06:02 <uvirtbot> Launchpad bug 1342274 in neutron "auth_token middleware in keystoneclient is deprecated" [Undecided,In progress]
21:06:14 <dolphm> which i alluded to in a keystone 1:1 #info
21:06:38 <dolphm> basically we've split auth_token into it's own package so keystoneclient doesn't have to carry wsgi deps
21:06:42 <devananda> dolphm: what should I look for to determine if ironic is affected? I am fairly sure we use that ...
21:06:50 <ttx> dolphm: would be cool to complete it for juno-2, just in case packagers take it
21:07:01 <dolphm> so, bknudson is proposing patches to switch everyone over to keystonemiddleware.auth_token
21:07:05 <eglynn> Brant Knudson is gonna push the changes across all projects? ... nice :)
21:07:16 <dhellmann> dolphm: does that apply for stable branches, too, or just juno and beyond?
21:07:22 <ttx> Brant Knudson wants to vote for all PTLs elections
21:07:33 <eglynn> ttx: LOL :)
21:07:44 <mikal> Similarly, I've just released a new python-novaclient that should hopefully address Heat's problems (thanks heaps to russellb for the fix)
21:07:47 * devananda waits for the split to finish
21:07:55 <ttx> ...
21:08:09 <dolphm> dhellmann: good question... we shouldn't affect previous stable branches
21:08:11 <dolphm> erm, net split?
21:08:22 <ttx> dolphm: yes, but quick one
21:08:32 <ttx> magnitude 4
21:08:38 <dhellmann> dolphm: ok, good
21:08:39 <devananda> bknudson: are you also proposing updates to incubated projects (eg ironic)?
21:08:48 <devananda> bknudson: or have an example somewhere I can copy?
21:09:08 <ttx> devananda: https://review.openstack.org/#/c/102342/
21:09:16 <bknudson> devananda: https://review.openstack.org/#/q/branch:master+topic:keystonemiddleware,n,z
21:09:23 <dolphm> devananda: you can borrow the approach in nova's patch https://review.openstack.org/#/c/102342/
21:09:30 <bknudson> those are the ones that are proposed to the projects I had repos for
21:09:50 <devananda> ack
21:09:56 <ttx> ok, other highlights from the 1:1 syncs that you want to make ?
21:10:05 <bknudson> it's generally only a couple of lines... ceilometer had some tests that were using internals of auth_token so had more changes
21:10:18 <ttx> #topic Other program news
21:10:22 <ttx> Infra, QA, Docs... anything you'd like to mention ?
21:10:25 <eglynn> bknudson: ... always the wayward child ;)
21:11:12 <annegentle> ttx: did I mention already that there's a template for incubating teams for oslosphinx now?
21:11:13 <ttx> guess not
21:11:16 <ttx> ah
21:11:23 * annegentle was typing
21:11:26 <ttx> annegentle: I.. don't think you did
21:12:18 <ttx> annegentle: link?
21:12:24 <annegentle> ttx: the configuration is in the oslosphinx README.rst
21:12:36 <ttx> ok, cool
21:12:37 * annegentle looks
21:12:43 <dhellmann> #link https://pypi.python.org/pypi/oslosphinx
21:12:59 <annegentle> #link http://git.openstack.org/cgit/openstack/oslosphinx/tree/README.rst
21:13:03 * dhellmann makes a note to write some documentation for the documentation theme package
21:13:10 <annegentle> default is non-incubating
21:13:31 <annegentle> dhellmann: yeah I had it in one of the What's Up Doc but wanted to be sure people know
21:13:51 <dhellmann> annegentle: good idea
21:13:55 <ttx> #info Expect keystonemiddleware support patches: https://bugs.launchpad.net/nova/+bug/1342274
21:13:57 <uvirtbot> Launchpad bug 1342274 in neutron "auth_token middleware in keystoneclient is deprecated" [Undecided,In progress]
21:13:57 <annegentle> ttx: that's all for now from docs
21:14:08 <ttx> ok, next topic then
21:14:11 <ttx> #topic Surprise last-minute blueprints, or code being developed in parallel with specs
21:14:22 <ttx> I wanted to reflect back on the -specs experience from the viewpoint of feature predictability
21:14:34 <ttx> One of the things we want to communicate out is a list of probably incoming features
21:14:46 <ttx> We do that using the blueprint system, and produce integrated views at http://status.openstack.org/release/
21:14:56 <ttx> Which are used by various downstream stakeholders
21:15:07 <ttx> It's always been difficult to predict correctly, but we must try to make sure this communication represents our best approximation
21:15:20 <ttx> I was hoping that the -specs process and the "clean" blueprint views (with only spec-approved and priority-set blueprints present in milestone pages) would actually improve our prediction
21:15:33 <ttx> But it looks like in lots of projects we have the opposite result...
21:15:41 <annegentle> and you found... ah.
21:15:44 <ttx> Specs and code are being developed at the same time, so specs approved very late in a milestone can still have code that actually makes it
21:15:45 <eglynn> ttx: yeap, that's been the reality in my experience
21:15:49 <devananda> In Ironic, I've seen most of the predictable features being implemented in parallel with the spec
21:15:59 <ttx> Since unapproved specs do not appear in the milestone pages, this results in last-minute addition of targeted blueprints
21:15:59 <eglynn> devananda: same in ceilo
21:16:07 <devananda> OTOH, the much larger features have benefitted immensely (IMO) from the forethought required by a specs process
21:16:12 <ttx> So I feel like we actually had better prediction BEFORE, with blueprints appearing on the release radar earlier
21:16:14 <dolphm> devananda: i would agree with that
21:16:20 <SlickNik> devananda: That's been my experience with trove as well.
21:16:22 <russellb> i feel like in nova, it definitely at least throttled blueprint approval
21:16:26 <dhellmann> devananda: +1
21:16:27 <ttx> Do you think it is a systemic issue with the -specs workflow, or just a temporary side-effect until we build a healthy spec/implementation pipeline ?
21:16:30 <devananda> so things that require a full cycle or more end up with no BP targeted at all for a while
21:16:31 <eglynn> devananda: maybe apply specs process more selectively?
21:16:32 <mestery> Some of that has happened in neutron as well
21:16:34 <mikal> russellb: agreed
21:16:47 <devananda> actually
21:16:50 <mikal> I think its also caused a lot of frustration from developers, but got people to focus on some stuff we really needed
21:16:53 <mestery> ttx: I'd like to think it's a temporary issue as people get used to the specs repo workflow, but maybe I'm just dreaming.
21:16:53 <mikal> Like the vmware refactor
21:16:54 <eglynn> i.e. only require for the larger features?
21:16:56 <devananda> I would really like to be able to target BPs before approving them
21:16:59 <devananda> it's crazy, i know
21:17:06 <devananda> but as a way of expressing my intent
21:17:15 <russellb> mikal: maybe that's just an effect specific to a larger project more overwhelmed with crap blueprint submissions
21:17:17 <devananda> "I think we should do $this before $that"
21:17:21 <devananda> even if both are still in the spec process
21:17:30 <dhellmann> devananda: I did that for planning before the summit
21:17:41 <russellb> mikal: the throttling (and more realistic roadmap) effect i mean
21:17:46 <zaneb> ttx: I think launchpad issues will only be fixed by replacing launchpad. specs is just a better place than the wiki/ML to comment on designs
21:17:48 <devananda> i've used a google doc to capture the results of the summit prioritization meeting we had
21:17:49 <ttx> devananda: so we could do that... use some weird Launchpad status to track that a spec is actually blocked because it's not approved yet
21:17:54 <notmyname> seems that -specs are a tool for devs and blueprints are a tool for project managers. which is why -specs have been largely cheered and blueprints largely booed. so I wouldn't expect -specs to solve a project manager problem
21:18:06 <devananda> notmyname: well said
21:18:11 <zaneb> notmyname: ++
21:18:21 <eglynn> ain't that the truth
21:18:24 <dolphm> keystone tried to implement a solution to this and sort of fell on our face by overly complicating the -spec process... but the gist was for -specs to be proposed & approved first with ONLY a problem description (no proposed solution) ... seemed like a good idea at the time
21:18:54 <dolphm> and later move those problem descriptions from a next/ dir to juno/ or whatever with a proposed solution
21:18:55 <devananda> the real benefit I've seen with specs has been in sussing out the implications of a change
21:19:06 <eglynn> dolphm: fell on it's face because it was too subtle a process?
21:19:07 <dhellmann> we've been slow to approve specs in oslo, but we've definitely caught issues in the process
21:19:28 <dolphm> eglynn: added too many extra steps for spec writers, and gerrit diffs weren't terribly useful
21:19:42 <ttx> I think we can fix the black hole that we created in Launchpad while still keeping the specs process and retaining LP as a downstream communication tool
21:19:57 <ttx> for example by using Blocked as a status
21:20:05 <eglynn> so I think the specs process has differing value depending on the chunkiness and/or radical nature of the proposed change
21:20:22 <ttx> to communicate that the spec is expected to be approved but not there yet
21:20:50 <russellb> ttx: that sounds like it could work
21:20:56 <russellb> ttx: or at least proposed and not approved?
21:21:16 <dhellmann> ttx: there are separate fields for approving the definition and the direction, would it make sense to use those?
21:21:21 <mestery> ttx: That's what I did with a few BPs to be honest
21:21:30 <russellb> how would you differentiate between stuff not yet approved and stuff not yet approved, but we think it probably will be soonish
21:21:35 <mestery> I used blocked for that on a few, but was inconsistent.
21:21:39 <devananda> ttx: eg, direction:approved, definition:drafting, implementation:blocked, milestone:$something ?
21:21:43 <dhellmann> "this blueprint identifies a problem we want to fix -- definition approved" vs. "this solution looks like it is correct -- direction approved"
21:21:55 <ttx> devananda: yes
21:21:58 <annegentle> dhellmann: that's a really really good point
21:22:01 <devananda> ttx: +1
21:22:05 <ttx> I can tweak spec2bp to facilitate setting the rigth statuses
21:22:10 <dolphm> does everyone expect a bp to be created first, or a spec?
21:22:15 <devananda> dolphm: same time
21:22:21 <eglynn> dolphm: spec first
21:22:24 <dolphm> devananda: when the spec is proposed or merged?
21:22:34 <devananda> dolphm: bp should be registered when the spec is proposed
21:22:35 <mikal> We ask for a URL to the bp in the spec
21:22:43 <dhellmann> yeah, I had to go rename quite a few bps but the spec is supposed to link to them so they both come into being around the same time
21:22:43 <devananda> ^ exactly
21:22:57 <ttx> so spec2bp would set the spec "blocked" while not approved, and clear that when the spec is approved
21:23:04 <dolphm> mikal: on my latest spec, i just made up an intended url, and opened the bp when the spec was merged :-/
21:23:20 <mestery> dolphm: BP then spec, that makes it easier, as the spec includes a link to the BP (at least for neutron)
21:23:23 <dhellmann> ttx: blocked vs. setting the direction/definition approval separately?
21:23:37 <ttx> dhellmann: in addition to
21:23:49 <ttx> spec2bp would help setting all that's needed
21:24:00 * dhellmann is going to need new instructions for how to put a bp in a milestone without having it removed
21:24:05 <ttx> hehe
21:24:43 <ttx> dhellmann: the only thing that gets you removed is missing priority
21:24:53 <dhellmann> ok
21:25:17 <ttx> I'll come up with a proposal and tooling to help setting stuff in LP without having to interact with the UI
21:25:37 <dhellmann> one other thing on spec2bp
21:25:49 <dhellmann> as I said, I had trouble with names not matching up a few times
21:25:56 <ttx> I think that will reduce the under-the-radar- flying we seem to have inadvertantly created
21:26:27 <dhellmann> can that be made smarter somehow? (not sure how smart we want it to be)
21:26:34 <dhellmann> maybe look at the link in the spec?
21:26:47 <ttx> is there always a link in the spec ?
21:26:53 <ttx> I can make it follow it when there is one
21:26:55 <dhellmann> well, we could say that's required
21:26:59 <russellb> should be, there's a field for it
21:27:16 <dhellmann> russellb: everyone has a slightly different template, I think, but we can at least agree on that
21:27:30 <ttx> it could also support a --bp option to point to right BP when they don't match, but atht would be a bit of a hassle to specify
21:27:54 <dhellmann> ttx: yeah, I would probably just write myself a wrapper to grep the link out in that case :-)
21:27:58 <russellb> dhellmann: ah, right ... i was thinking of the other way, the spec field in the blueprint itself
21:28:14 <russellb> but yeah, standardizing on having a blueprint link in a spec seems quite reasonable
21:28:17 <ttx> #action ttx to come up with a proposal to use "blocked" in addition to approval fields and tooling to help setting stuff in LP without having to interact with the UI
21:28:58 <ttx> #info spec2bp should better support the case where spec and BP names don't match
21:29:42 <ttx> I think that will solve the issue
21:29:57 <ttx> #topic Open discussion
21:30:01 <ttx> Anything else, anyone ?
21:30:11 <mikal> Similarly, I've just released a new python-novaclient that should hopefully address Heat's problems (thanks heaps to russellb for the fix)
21:30:22 <mikal> ^-- repasted from above when I said it mid split
21:30:28 <ttx> russellb: will you run this meeting next week ?
21:30:36 <russellb> ttx: sure
21:30:54 <ttx> russellb: only if you have some use for it, or some agenda posted for it
21:31:06 <russellb> i don't have anything now ...
21:31:12 <russellb> ad-hoc syncs around j2 are probably fine
21:31:27 <russellb> otherwise this meeting will just be old-style, going through each project
21:31:33 <russellb> let's just skip.
21:31:47 <ttx> russellb: ok
21:31:59 <ttx> #info no meeting next week, contact russellb directly for juno-2 sync
21:32:17 <russellb> i'll hang out in #openstack-relmgr-office as a convenient place to sync with everyone
21:32:19 <eglynn> ... and no 1:1s either?
21:32:28 <devananda> russellb: will you be at the nova sprint?
21:32:34 <russellb> devananda: yes, but that's the week after
21:32:40 <devananda> ah, right
21:32:42 <ttx> eglynn: there will be 1:1 discussions, but not at the scheduled time
21:32:51 <ttx> eglynn: russellb will contact you directly
21:32:52 <eglynn> ttx: cool, got it
21:33:00 <russellb> or you can ping me
21:33:03 <russellb> pinging will occur.
21:33:04 <devananda> russellb: i apparently can't keep track of time :)
21:33:09 <ttx> pinging is a thing
21:33:37 <ttx> In other news, one more day to vote on K naming
21:33:43 <russellb> vote for Kilo!
21:33:56 <mikal> OMG, yes please
21:34:00 <mikal> Its time we went metric
21:34:07 <mestery> ++
21:34:25 <eglynn> russellb: I'm goning to report you for inappropriate attempts influence an election!
21:34:30 <russellb> :(
21:34:36 <ttx> on a public forum though!
21:34:48 <SlickNik> annegentle: We've spent some time identifying holes in the trove docs. We're currently working on fixing these up.
21:34:56 <ttx> I rule it as fair campaigning. Unless you encourage voting for Kyoto
21:35:00 <markwash> its all about kleber
21:35:03 <SlickNik> annegentle: https://etherpad.openstack.org/p/trove-doc-items FYI - wanted to keep you in the loop.
21:35:07 <dhellmann> markwash: +1
21:35:26 <eglynn> dhellmann when is the next oslo-messaging release expected?
21:35:40 * eglynn would like to get our hands on the fix for https://bugs.launchpad.net/oslo.messaging/+bug/1342088
21:35:44 <uvirtbot> Launchpad bug 1342088 in oslo.messaging "Exchanges lock disregarded in the fake driver implementation" [Low,Fix committed]
21:36:09 <dhellmann> eglynn: we can make a release tomorrow, let me check with markmc to make sure he's not waiting for something else first
21:36:15 <eglynn> (may be related to the strange timeout issue we're seeing in a test in ceilo that uses RPC fanout)
21:36:24 <eglynn> dhellmann: great, thank you sir!
21:36:45 * russellb can't wait to get his hands on a Kilo of OpenStack
21:37:01 <eglynn> also seeing as the QA folks are all in conclave this week, might not be the best time to bring this up ... but
21:37:15 <eglynn> towards the tail-end of that branchless Tempest ML thread I kicked off after last week's meeting
21:37:17 <SlickNik> dhellmann: We're also making good progress moving trove to oslo.messaging. (FYI https://review.openstack.org/#/c/94484/)
21:37:28 <eglynn> ... the wind was blowing in the direction of pushing functional test suites into the individual projects
21:37:40 <eglynn> e.g. http://lists.openstack.org/pipermail/openstack-dev/2014-July/040128.html
21:37:41 <dhellmann> SlickNik: fantastic! :-)
21:37:41 <ttx> eglynn: it did indeed
21:37:44 <dhellmann> eglynn: email sent
21:38:00 <dhellmann> russellb: careful not to make that joke in a US airport
21:38:15 <russellb> dhellmann: i may be on a list for saying it on IRC
21:38:22 <dhellmann> russellb: I don't know you.
21:38:23 * eglynn wonders if we need some sort of cross-project discussion/aggreement to avoid all rushing off in different directions on that?
21:38:34 <russellb> eglynn: +1
21:38:39 <SlickNik> dhellmann: esp who's been working on getting it done, tells me he still has a few kinks to work out, but we're looking forward to getting that landed soon. Will keep you posted on the progress on that front. Thanks!
21:38:47 <russellb> on the need for careful coordination at least :)
21:39:07 <ttx> eglynn: I hope it will be a topic at the QA sprint
21:39:27 <dhellmann> eglynn: is that a topic for a cross-project summit session or are you hoping to have it resolved before then?
21:39:27 <eglynn> ttx: k, prolly should wait on an explicit report back from the sprint
21:39:42 <eglynn> dhellmann: yes, leastways a K* summit session
21:39:48 <dhellmann> SlickNik: sounds good, thanks for keeping us updated
21:39:54 <ttx> eglynn: i feel like the proposal was mostly set up as a strawman, not a fully-formed direction yet
21:40:05 <ttx> so it should solidify first
21:40:06 <eglynn> ttx: yes, I got that impression also
21:40:32 <eglynn> ok, fair nuffski if no one is rushing off the blocks yet
21:41:08 <ttx> ok, anything else before we close?
21:42:01 <ttx> well, then...
21:42:04 <ttx> #endmeeting