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