12:00:09 <alex_xu> #startmeeting nova api
12:00:10 <openstack> Meeting started Tue Aug 11 12:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:13 <openstack> The meeting name has been set to 'nova_api'
12:00:25 <alex_xu> anyone at here today?
12:00:35 <alex_xu> as we have new meeting time for this meeting
12:00:46 <claudiub> o/
12:00:52 <alex_xu> claudiub: hi
12:01:01 <claudiub> hellou :)
12:01:39 <alex_xu> waiting one more minutes to see if more people join
12:01:45 <claudiub> ofc
12:01:49 <johnthetubaguy> hello
12:01:54 <sdague> hey all
12:02:01 <alex_xu> hello!
12:02:46 <alex_xu> #topic Actions from last meeting
12:03:11 <alex_xu> one for johnthetubaguy, about catch with me about api work status, I think its done
12:03:26 <johnthetubaguy> roughly done, yes
12:03:32 <alex_xu> another for sdague, we have new agenda!
12:03:37 <alex_xu> #link https://wiki.openstack.org/wiki/Meetings/NovaAPI
12:03:43 <sdague> yep, done - woot
12:03:43 <johnthetubaguy> +1
12:03:47 <alex_xu> sdague: thanks for the new agenda!
12:04:04 <alex_xu> let's moving on
12:04:11 <sdague> so I feel like that's roughly the right standing agenda, but if people think other major sections should be there just speak up
12:04:12 <alex_xu> #topic API infrastructure
12:04:43 <alex_xu> sdague: yea, that help to track our work also
12:05:00 <alex_xu> first one, 'v2.0 on v2.1'
12:05:16 <alex_xu> any command for sub topic?
12:05:26 <sdague> alex_xu: not really
12:05:33 <sdague> you can change #topic
12:05:40 <sdague> or not, depending on how you feel
12:05:45 <alex_xu> #topic v2.0 on v2.1
12:06:06 <alex_xu> for relax api validation, there only left one patch
12:06:08 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-relax-validation,n,z
12:06:32 <sdague> #info 3 of 4 patches merged for API validation relaxation needed for v2.0 on v2.1
12:06:42 <alex_xu> sdague: thanks
12:06:57 <sdague> alex_xu: ok, great, anything else needed, or do we think that with that final patch we're good?
12:07:22 <johnthetubaguy> I think the next step is reaching out for folks to test it out
12:07:26 <alex_xu> sdague: no more, from my view, the final patch is good
12:07:36 <sdague> do we have a tempest job set up for this configuration?
12:07:39 <johnthetubaguy> I think mikal had offered to help with that
12:07:40 <sdague> even in experimental
12:07:45 <johnthetubaguy> sdague: good point, that too
12:08:29 <alex_xu> so we create new job for this?
12:08:49 <johnthetubaguy> to test it out, I think we should
12:09:00 <johnthetubaguy> once thats green we could look at moving the existing jobs over
12:09:06 <sdague> ok, I can take that one for next week
12:09:22 <johnthetubaguy> maybe neutron jobs all run v2.1 for v2, non-network stay on the old?
12:09:22 <sdague> #action sdague to build experimental devstack/tempest job to test v2.0 on v2.1
12:09:25 <johnthetubaguy> sdague: would that work?
12:09:47 <johnthetubaguy> s/non-network/nova-network/
12:09:52 <alex_xu> sdague: thanks
12:10:10 <sdague> johnthetubaguy: so, let's prove it works. We probably need to rethink the overall test plan for Nova about what's important and trim our jobs accordingly
12:10:16 <sdague> but that's a different conversation
12:10:57 <johnthetubaguy> sdague: +1 to all that
12:11:05 <sdague> ok, I think we can move on from this one. I'll review the patch once the meeting is over
12:11:07 <johnthetubaguy> I am getting ahed of my self
12:11:12 <johnthetubaguy> +1
12:11:20 <alex_xu> cool
12:11:43 <alex_xu> sdague: after the test job, then we can change the endpoint?
12:12:09 <sdague> alex_xu: yeh, I think so, we just have to have a story on what existing installs will do
12:12:25 <sdague> let me poke at it a bit and I'll let you know
12:12:38 <alex_xu> sdague: ok, thanks
12:12:53 <alex_xu> #topic policy.json updates to remove admin hard code at the db level
12:13:11 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z
12:13:16 <alex_xu> just left three patches
12:13:27 <sdague> are we done done after those 3 patches?
12:13:35 <alex_xu> sdague: yes, we are done
12:13:37 <sdague> because I feel like new patches always appear on this stop
12:13:40 <sdague> topic
12:13:43 <sdague> ok, awesome.
12:14:11 <sdague> #info 3 patches left to merge before policy.json updates to remove admin hard code at the db level is done
12:14:19 <sdague> that's a really nice place to be in
12:14:34 * sdague open another browser tab for reviewing code
12:14:57 <alex_xu> there are a lot of elvated context in the code, but we can cleanup them in the future
12:15:21 * johnthetubaguy also opens those patches for review
12:15:35 <alex_xu> heh...cool
12:15:38 <alex_xu> #topic Test collapse of v2.0 and v2.1
12:15:39 <sdague> alex_xu: ok, cool. Do you think those will be done this cycle or in Mitaka?
12:15:43 <johnthetubaguy> alex_xu: do we have a plan of when to do that,?
12:16:13 <alex_xu> in the M I think, we can create a bug for low hanging fruits
12:16:30 <alex_xu> good for new contributor in nova
12:16:37 <johnthetubaguy> I guess there is no reason to wait, maybe add it to the list next to log cleanups
12:16:56 <johnthetubaguy> #link https://etherpad.openstack.org/p/nova-low-hanging-fruit
12:16:59 <johnthetubaguy> its listed in here:
12:17:03 <johnthetubaguy> https://wiki.openstack.org/wiki/Nova/Mentoring
12:17:09 <sdague> yeh, but it would be good to track as API infrastructure cleanup in Mitaka cycle
12:17:36 <johnthetubaguy> +1 for tracking it, we can create a blueprint like we have for objects
12:17:37 <sdague> #info elevated_context cleanup will happen in Mitaka cycle
12:17:46 <johnthetubaguy> yeah, lets keep moving
12:17:52 <sdague> yeh, even with low hanging fruit we should set a timeline
12:18:03 <sdague> otherwise we get stuff like mox living forever
12:18:16 <sdague> agreed, back on topic :)
12:18:28 <sdague> ok, test collapse of v2.0 and v2.1
12:19:02 <alex_xu> #action /me create bp for elevated context cleanup and update low-hanging fruit etherpad
12:19:21 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:merge_sample_tests,n,z
12:19:40 <johnthetubaguy> is that list complete as well? or are there more patches to come?
12:19:44 <alex_xu> looks like more pach come up
12:19:57 <johnthetubaguy> so I am tempted to pause this, after these patches
12:20:01 <alex_xu> I'm not sure, we should check with gmann
12:20:07 <sdague> it would be good to get some idea about how far along we are
12:20:12 <sdague> even if just roughly
12:20:18 <sdague> like are we 50% done now?
12:20:20 <johnthetubaguy> yeah, very true
12:20:21 <sdague> 80% done
12:20:28 <alex_xu> and I think remove v3 depend on this
12:20:38 <alex_xu> when we move api sample tests
12:20:52 <sdague> well, we'll just move different files if this is done or not
12:20:53 <johnthetubaguy> alex_xu: it shouldn't have to, well I think remove v3 is way more important
12:20:58 <johnthetubaguy> sdague: +1
12:21:06 <sdague> and I agree, removing v3 in the tree is way more important
12:21:15 <sdague> it will definitely merge conflict with that
12:21:20 <johnthetubaguy> it would make it clearer if we have old_stuff and merged stuff in separate directories
12:21:25 <alex_xu> ok, there should be a way skip that
12:21:32 <johnthetubaguy> yeah, I am thinking we stop the merge to make sure the rename can happen
12:21:50 <johnthetubaguy> but anyways, lets get info on how close that is
12:22:10 <sdague> #info put merge of v2.0 / v2.1 tests on hold until v3 removal is complete
12:22:10 <johnthetubaguy> I am more worried about moving the API code rather than the tests, as silly as that sounds
12:22:19 <sdague> johnthetubaguy: yeh, I think that's fair
12:22:47 <sdague> and I think it's fair to put this on hold a bit, and focus on the v3 removal. We can merge test fixes / collapse after freeze as well, right?
12:22:59 <sdague> I thought tests and docs were typically fair game during the rc period
12:23:15 <johnthetubaguy> yeah, thats true
12:23:21 <johnthetubaguy> although I would rather be merging bug fixes
12:23:28 <sdague> sure
12:23:36 <johnthetubaguy> docs totally, not sure about the test clean ups
12:23:43 <johnthetubaguy> they sound like a distraction
12:23:51 <johnthetubaguy> although back port problems are good to avoid
12:24:12 <sdague> maybe, I feel like they are typically not very hard to review, and make things easier later
12:24:48 <sdague> anyway, we're agreed to pause on the test collapse for now?
12:24:53 <sdague> if so, I think we can move on
12:25:05 <alex_xu> sdague: or check with gmann first?
12:25:15 <sdague> oh, I guess there is an action for gmann to get a status on how complete the whole effort is
12:25:20 <johnthetubaguy> I think we delay for now, and check with gmann
12:25:32 <johnthetubaguy> lets report back here next week
12:25:33 <alex_xu> ok
12:25:47 <sdague> #action get status from gmann on overall completeness of the v2.0 / v2.1 test collapse
12:26:01 <johnthetubaguy> its a soft freeze, I don't want to -2 them all, thats a waste of time, if they merge, they merge
12:26:13 <sdague> yeh
12:26:37 <alex_xu> ok, let's move on
12:26:39 <sdague> though, honestly, kenichi and I are typically the only ones reviewing them, so I doubt they will merge without us actively pushing it
12:26:48 <sdague> alex_xu: +1
12:27:10 <johnthetubaguy> sdague: exactly my thinking
12:27:14 <alex_xu> sdague: yea, I help few review before and will continue
12:27:29 <alex_xu> #topic Removal of v3 naming from source tree
12:27:31 <sdague> alex_xu: right, sorry, I meant from a +2 perspective
12:27:50 <alex_xu> sdague: yea
12:28:10 <alex_xu> there are two patches for moving legacy v2 code is ready I think
12:28:12 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1462901,n,z
12:28:26 * edleafe didn't realize the meeting moved already
12:28:32 <sdague> ok, great. I'll look hard at these right after the meeting
12:28:38 <alex_xu> sdague: thanks
12:28:46 <edleafe> morning, alex_xu
12:28:53 <edleafe> saw your commits
12:28:56 <alex_xu> edleafe: morning :)
12:28:57 <sdague> edleafe: it was a little adhoc, alex_xu asked, and I wasn't going to be here on friday, so said go for it :)
12:29:03 <edleafe> have you started on step 3 yet?
12:29:13 <alex_xu> not yet
12:29:17 <edleafe> sdague: cool. I'll adjust my calendar
12:29:30 <alex_xu> step 3 will be moving v2.1 code to toplelve
12:29:33 <edleafe> alex_xu: I can do that, since your day is winding down now
12:29:44 <alex_xu> edleafe: thanks
12:29:45 <sdague> alex_xu: so we should start with - https://review.openstack.org/#/c/211356/ right?
12:30:00 <sdague> there are 2 patch series listed under that bug
12:30:16 <alex_xu> sdague: yes
12:30:35 <alex_xu> edleafe: can you abandoned this one https://review.openstack.org/193725
12:30:55 <edleafe> alex_xu: yeah, I was planning on it
12:30:56 <alex_xu> edleafe: and I think we can move json-schema separately
12:32:12 <sdague> alex_xu: sounds reasonable. So I think that for these patches if we agree that changes are required, we should just respin among the team. I'd hate to delay these because folks are asleep.
12:32:17 <alex_xu> edleafe: for moving v3, should we create resource directory in one step.
12:32:28 <johnthetubaguy> sdague: +1
12:32:48 <johnthetubaguy> I think this small steps approach is proving way easier to review, lets keep it going
12:33:01 <sdague> lets kind of keep an active conversation going in #openstack-nova during the day until we get them merged
12:33:11 <johnthetubaguy> if we are worry about partial merges of the chain, I think we can sort that out later
12:33:25 <alex_xu> ++
12:33:26 <johnthetubaguy> sdague: I wonder if we want to block the first one till we have a good few lined up?
12:33:37 <edleafe> sdague: should we -W them until they are all ready? Then release them all at once to avoid multiple rebase hell?
12:33:49 <sdague> johnthetubaguy: honestly, as long as we are committed to getting this in regardless, let's just grind on them
12:33:50 <edleafe> johnthetubaguy: jinx (sort of)
12:34:38 <sdague> because procedural stuff just triggers various additional delays, we end up in a situation where something is wip, the author is asleep, and then we need to get 3 hrs of testing rerun to merge
12:34:41 <edleafe> alex_xu: not sure what you mean
12:34:41 <edleafe> alex_xu: about the resource directory
12:34:47 <alex_xu> the v2 moving can waiting for v2.1 moving, I guess there isn't too much conflict for v2 moving
12:35:14 <sdague> alex_xu: can we get an etherpad with what you think the various additional patches would be?
12:35:22 <johnthetubaguy> sdague: OK, that makes sense
12:35:25 <sdague> then we can get details there as well about next steps
12:35:44 <alex_xu> sdague: ok, will create one after the meeting
12:35:48 <sdague> alex_xu: thank you
12:35:59 <alex_xu> edleafe: let's talk about v3 step off the meeting
12:36:07 <edleafe> alex_xu: sure
12:36:21 <alex_xu> let's move on
12:36:25 <alex_xu> #topic API Documentation Improvement
12:36:36 <alex_xu> sdague: ^ any idea?
12:36:52 <sdague> a couple of things
12:37:21 <sdague> I spoke with annegentle last week about how to get a new concept guide published to the API site. She's going to help with that infrastructure.
12:37:49 <sdague> We need to write that concept guide. Honestly, I expect that will wait until we get these release critical patches merged.
12:38:13 <sdague> once we do, I'll write up a documentation plan and start in on some of that content
12:38:18 <sdague> and hopefully get others to participate
12:38:31 <alex_xu> sdague: cool
12:38:48 <sdague> that's it on that topic so far, I hope we'll get more focus on it in Mitaka
12:38:55 <alex_xu> sdague: release critical patches means ?
12:39:10 <sdague> the v3 remove
12:39:15 <alex_xu> this is Mitake work item?
12:39:37 <sdague> alex_xu: honestly, I hope we get some of it done before the release
12:39:38 <alex_xu> s/Mitake/Mitaka....
12:40:00 <alex_xu> sdague: ok
12:40:00 <sdague> documentation doesn't go into freeze the same way as the rest of the release
12:40:44 <sdague> we can move on to the next couple of topics
12:40:59 <alex_xu> #topic API futures - specs
12:41:16 <alex_xu> nothing listed at here
12:41:25 <alex_xu> so let move on?
12:41:36 <johnthetubaguy> there are some in the etherpad I guess
12:41:40 <johnthetubaguy> but fixes that needed specs
12:41:54 <johnthetubaguy> I think I have +2ed them, but need to get other drivers to approve them
12:42:04 <johnthetubaguy> sorry, I got distracted with the previous docs topic
12:42:07 <sdague> so, the intent here is we should have a list of all specs with API changes in them that are up for review
12:42:29 <johnthetubaguy> I think we agreed docs was the most important thing for liberty, so I would love to see some progress there, however small it is
12:42:31 <sdague> because, in reviewing some of the API changes in code, we had some late fixes needed
12:42:43 <sdague> which has blocked a few of those for the release
12:42:54 <johnthetubaguy> yeah, there are a few of those, we should keep tracking them
12:43:03 <sdague> johnthetubaguy: are all nova-specs with API changes getting tagged with APIImpact currently?
12:43:17 <sdague> if not, could we ask for that
12:43:24 <johnthetubaguy> sdague: they should be, we usually add it if not
12:43:35 <johnthetubaguy> sdague: we do ask for it already, just no everyone does it
12:43:47 <johnthetubaguy> s/just no/just not/
12:44:42 <alex_xu> sdague: you want to go through all the apiimpact spec in this topic?
12:44:42 <edleafe> I've seen several reviews in the last cycle where reviewers asked to add APIImpact
12:44:44 <sdague> ok, something isn't working with that query
12:45:09 <sdague> #action sdague to find gerrit query to pull all API changed specs
12:46:05 <alex_xu> I have link for dashboard
12:46:07 <alex_xu> https://review.openstack.org/#/dashboard/?title=Nova+API+Spec+Dashboard&foreach=project:openstack/nova-specs&Reviewed+by+me=reviewer:xuhj+is:open+message:apiimpact&Recently+Closed+And+Reviewed+by+me=is:closed+limit:15+message:apiimpact&Recently+Closed=is:closed+reviewer:self+limit:30+message:apiimpact&Open=is:open+message:apiimpact
12:46:13 <alex_xu> hope this helpful
12:46:35 <sdague> oh, it has to be lower case
12:46:40 <sdague> ok, good call
12:47:08 <sdague> so once specs get approved for the cycle, we should then also be tracking all the patches that are relevant to those changes
12:47:14 <sdague> which would be the next topic
12:47:36 <sdague> that will probably require a query that we keep updated with the latest approved blueprints for that cycle
12:48:00 <alex_xu> sdague: ok
12:48:22 <alex_xu> from the priorit etherpad
12:48:37 <alex_xu> I think there is one api bug fix is more important
12:48:39 <alex_xu> #link https://review.openstack.org/#/c/198622/2
12:49:08 <sdague> johnthetubaguy: ^^
12:49:08 <alex_xu> it's about we missing porting an API from v2 to v2.1
12:49:27 <alex_xu> and we already get agreement on how to fix it
12:49:31 <johnthetubaguy> yeah, that ones important
12:49:33 <sdague> johnthetubaguy: iirc the functional code for that is ready to go, it just needs procedural approval
12:49:36 <johnthetubaguy> I had +2ed it, it lost that vote
12:50:01 <johnthetubaguy> so I thought I reached out to some driver folks, but doesn't seem like any of them got to that
12:50:09 <johnthetubaguy> lets re-apply our +1s as a start
12:51:03 <sdague> done
12:51:06 <alex_xu> ok, no more on this topic, maybe next week
12:51:19 <sdague> I think the last thing is the 'nmi' interface
12:51:28 <sdague> just to round up where we stand on that
12:51:49 <sdague> I -1ed that patch because it's weird semantics for our API
12:52:06 <sdague> and I feel like it should have been "crashdump" in the API, and nmi is an implementation detail
12:52:11 <alex_xu> #link https://review.openstack.org/#/c/202617/
12:52:37 <sdague> given timing, we probably need to revisit the interface in mitaka
12:52:50 <sdague> johnthetubaguy: that your feeling as well?
12:53:58 * alex_xu need think about more
12:55:00 <sdague> ok, well johnthetubaguy has -2ed it, so we'll revise next cycle
12:55:20 <alex_xu> ok...let's move on
12:55:22 <johnthetubaguy> yeah, it feels like the deadline has passed for new features now
12:55:39 <johnthetubaguy> (sorry being bombarded in openstack-nova)
12:55:43 <sdague> no prob
12:55:52 <alex_xu> #topic API futures - patches for approved specs
12:56:03 <alex_xu> anything for this?
12:56:06 <sdague> alex_xu: well, we were kind of just on that topic :)
12:56:14 <edleafe> the nmi stuff feels like the cpu features
12:56:14 <sdague> so let's just jump to open discussion
12:56:18 <alex_xu> sdague: yea...
12:56:22 <alex_xu> #topic open
12:56:25 <edleafe> too specific to an architecture
12:56:35 <alex_xu> I forget to ask, what plan for removing extension?
12:56:57 <sdague> I have one question. I'm going to write up the extensions deprecation document this week, so we can have some clarity
12:57:11 <sdague> but my question is "where" should it be
12:57:12 <edleafe> alex_xu: aren't they supposed to be deprecated in Liberty?
12:57:14 <alex_xu> we are pretty late for this. maybe just deprecate some config option for extension for this release?
12:57:33 <sdague> because, this partially feels like a liberty spec, even though late
12:57:44 <alex_xu> edleafe: we want to
12:57:47 <sdague> it could be devref (but it feels like a spec)
12:58:07 <alex_xu> and next week is propose freeze
12:58:13 <edleafe> if it's going away, probably not devref, right?
12:58:17 <sdague> I don't want to make it a backlog or mitaka spec because we do really want to flag extensions as a deprecated topic before we're done
12:58:24 <sdague> with liberty
12:58:34 <sdague> johnthetubaguy: need some guidance here
12:58:57 <johnthetubaguy> so I think we need to deprecate those configs
12:58:57 <alex_xu> I think let's check if we can do thing for user visible thing first
12:59:10 <johnthetubaguy> I am happy to just approve a blueprint for that, unless we feel it needs a spec?
12:59:50 <sdague> johnthetubaguy: well I'm happy to write up the overall spec with items that get done for liberty in there
13:00:08 <sdague> I feel like the whole of the transition to no extensions is probably spec worthy
13:00:28 <sdague> there seems to be a lot of confusion at times, and there have been nova channel fights over it, so we should write down the whole path
13:00:40 <johnthetubaguy> is there stuff beyond deprecating the configs that we need to merge this cycle?
13:00:52 <johnthetubaguy> sdague: yeah, thats very, very true
13:01:10 <sdague> johnthetubaguy: we should also merge some document that signals this is going away for real in a couple of cycles
13:01:17 <johnthetubaguy> +1
13:01:22 <sdague> beyond just config deprecation
13:01:25 <johnthetubaguy> I think we could do that in devref in those patches
13:01:36 <sdague> johnthetubaguy: ok, devref it is
13:01:37 <alex_xu> we run out of time....
13:01:39 <sdague> yep
13:01:48 <johnthetubaguy> sdague: let me know the BP, and I can get that approved
13:01:54 <sdague> sure
13:02:00 <johnthetubaguy> sdague: I think thats the best option this late in the cycle
13:02:10 <johnthetubaguy> (given how hard it was to merge the other specs at this point)
13:02:12 <sdague> yep, thanks folks
13:02:26 <alex_xu> yea, thanks all, let move to openstack-nova
13:02:30 <sdague> johnthetubaguy: ok, I'll do a futures spec for the whole arc then
13:02:33 * johnthetubaguy feels happier about the progress reports now, thank you sdague!
13:02:35 <alex_xu> #endmeeting