12:00:12 <alex_xu> #startmeeting nova api
12:00:13 <openstack> Meeting started Fri Jun  5 12:00:12 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:17 <openstack> The meeting name has been set to 'nova_api'
12:00:20 <gillliard> Hello!
12:00:27 <alex_xu> hello!
12:01:06 <gillliard> ha - just us 2 then?
12:01:12 <alex_xu> emm...sdague can't join the meeting, but leave some note before the meeting
12:01:19 <alex_xu> gillliard: ha yea
12:01:34 <eliqiao> hi
12:01:40 <gillliard> hey :)
12:01:44 <alex_xu> eliqiao: hi
12:01:57 <gillliard> Maybe wait a couple more minutes to see if anyone else shows up?
12:02:08 <alex_xu> gillliard: ok
12:02:13 <eliqiao> :)
12:02:50 <alex_xu> if just three of us, we can go through item quickly
12:03:07 <bauzas> \o (waves late)
12:03:19 <alex_xu> bauzas: hello :)
12:03:21 <eliqiao> 0/ hi
12:03:22 <gillliard> hi bauzas
12:03:33 <bauzas> hey
12:03:41 <alex_xu> let's start the party~
12:03:47 <bauzas> good to see an API meeting cool for my TZ :)
12:04:06 <alex_xu> #topic Liberty work items and priority
12:04:09 <eliqiao> so bauzas: what's you tz?
12:04:17 <alex_xu> #link https://etherpad.openstack.org/p/liberty-api-working-list
12:04:28 <alex_xu> I summary this from summit etherpad, hope everybody can review it, and see if I missed something.
12:04:31 <bauzas> eliqiao: CET (now CEST)
12:04:49 <alex_xu> sdague already add some note
12:04:53 <gillliard> There's a few things in Liberty 1 there. What date does that mean?
12:05:06 <alex_xu> hope we can put the item into the milestone
12:05:24 <alex_xu> gillliard: the end of this month?
12:05:45 <gillliard> Shall we go through the liberty 1 items quickly then?
12:05:58 <alex_xu> yes, we can
12:06:16 <bauzas> gillliard: June 24th IIRC
12:06:24 <gillliard> OK that's quite soon!
12:06:27 <alex_xu> the first one is about sdague's blog, it already done
12:06:45 <bauzas> gillliard: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065819.html
12:06:47 <gillliard> #link https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
12:06:51 <johnthetubaguy> there are quite a few items in the roll up, I am guess most are duplicates: https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items
12:07:00 <alex_xu> thanks all :)
12:07:38 <gillliard> python novaclient microversions work. akurilin has a spec.
12:07:42 <gillliard> #link https://review.openstack.org/#/c/188410/
12:07:53 <alex_xu> johnthetubaguy: oops, I didn't notice that
12:08:23 <alex_xu> yea, the spec almost copy from ironic
12:09:10 <gillliard> I think it looks good, except some changes needed for the validation-relaxation stuff
12:09:10 <alex_xu> johnthetubaguy: I will check the duplicates item in https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items later
12:09:18 <johnthetubaguy> alex_xu: thanks
12:09:43 <alex_xu> gillliard: and it need something in server side, and you signup to work on it, right?
12:10:20 <gillliard> #action (gilliard) add min/max version headers to responses, update microversions spec accordingly
12:10:38 <alex_xu> gillliard: thanks, and better to add subitem under the novaclient one
12:11:05 <alex_xu> gillliard: but I think we should waiting for the microversion guildeline also
12:11:32 <alex_xu> "Restructure API tree to remove v3 and other confusing things"
12:11:54 <bauzas> you mean v2 ?
12:11:55 <alex_xu> Emm...not sure how hard it is, maybe just need some huge patch
12:12:04 <bauzas> or rename v3 ?
12:12:12 <gillliard> bauzas: rename v3
12:12:13 <alex_xu> bauzas: no, the v3. like plugins/v3...
12:12:15 <eliqiao> rename v3 to what ? v2.1?
12:12:32 <alex_xu> eliqiao: I think just remove the 'v3'
12:13:05 <gillliard> Do we have a volunteer for this one?
12:13:07 <bauzas> alex_xu: okay, you confused me with 'remove v3' :p
12:13:09 <eliqiao> it's not a interesting work
12:13:34 <gillliard> It will be really useful to un-confuse people though
12:13:36 <alex_xu> bauzas: sorry, I should say remove any 'v3' word from the code
12:13:56 <bauzas> alex_xu: it could be possibly something done by a newcomer right ?
12:14:12 <bauzas> alex_xu: I mean a git mv doesn't sound really hard
12:14:24 <alex_xu> bauzas: yes, I guess it won't too hard, but I didn't check the detail
12:14:41 <eliqiao> seen from #link https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items  johnthetubaguy: find someone to rename v3 to v2.1 in the treej
12:14:45 <bauzas> alex_xu: okay, my point is that we can possibly put that to the audience for someone wanting to ramp up on Nova
12:14:50 <alex_xu> bauzas: , I guess more than that
12:15:00 <bauzas> alex_xu: does that need a spec ?
12:15:00 <alex_xu> bauzas: a lot of 'import'
12:15:00 <eliqiao> remove v3 or  rename v3 to v2.1?
12:15:28 <bauzas> alex_xu: honestly, that's still not a big deal IMHO, just packaging stuff for Python
12:15:42 <alex_xu> bauzas: yea, good idea, do you know how to public that, in the ML?
12:15:54 <bauzas> alex_xu: I should discuss that with johnthetubaguy
12:16:14 <bauzas> alex_xu: because we have lots of dirty easy stuff to do which can be done by people wanting to contribute
12:16:22 <alex_xu> and we should ask johnthetubaguy about whether we need spec
12:16:33 <alex_xu> bauzas: yea
12:16:34 <bauzas> alex_xu: not sure it requires a spec IMHO
12:16:48 <alex_xu> bauzas: actually I prefer not
12:16:58 <bauzas> alex_xu: not planning to modify api-paste.ini ?
12:17:12 <alex_xu> bauzas: no, I guess not
12:17:19 <johnthetubaguy> alex_xu: which bit is that
12:17:26 <johnthetubaguy> oh, the rename
12:17:36 <bauzas> johnthetubaguy: yup
12:17:51 <johnthetubaguy> just do a bug to track that, and add it into the priority review etherpad, I guess?
12:17:58 <bauzas> indeed
12:18:02 <alex_xu> johnthetubaguy: we aren't rename to v2.1, we are going to remove v3, right?
12:18:10 <johnthetubaguy> I would say do a spec, to prove agreement, but we did that at the summit
12:18:23 <johnthetubaguy> alex_xu: yes, something like that
12:18:33 <bauzas> alex_xu: lots of projects are renaming stuff, that's quite easy
12:18:37 <johnthetubaguy> alex_xu: and remove the plugin name too
12:18:56 <bauzas> well, then maybe the spec is worth for mentioning how to do
12:19:00 <alex_xu> johnthetubaguy: plugin name is?
12:19:03 <johnthetubaguy> alex_xu: the issue is the old stuff, we can't move that too far, because of the config, or we have to fix the config
12:19:08 <johnthetubaguy> alex_xu: let me get a link
12:19:30 <johnthetubaguy> alex_xu: https://github.com/openstack/nova/tree/master/nova/api/openstack/compute/plugins/v3
12:19:48 <johnthetubaguy> alex_xu: basically we can move them all to the top level, if we can move the current stuff into some v2.0 directory
12:20:17 <johnthetubaguy> alex_xu: assuming that doesn't need any config changes for the deployer (and paste.ini mess)
12:20:29 <alex_xu> johnthetubaguy: you mean under the nova/api/openstack/compute?, that will have name conflict with v2 api file
12:20:43 <johnthetubaguy> alex_xu: right, they would need moving somewhere, if possible
12:20:52 <bauzas> given the convo, I think now a spec is worthwhile :)
12:21:00 <johnthetubaguy> alex_xu: that or move it somewhere better, like we can drop the ec2 bit
12:21:06 <bauzas> because I would propose some stuff
12:21:18 <johnthetubaguy> bauzas: yeah, I was just thinking that, but... its easier to discuss this in the code review, probably
12:21:30 <johnthetubaguy> it has to "look nice" and not affect config
12:21:57 <johnthetubaguy> I am happy to do a spec, if you prefer, I am not planning on requiring it
12:22:26 <alex_xu> johnthetubaguy: ok, then find someone help on coding
12:22:50 <alex_xu> johnthetubaguy: thanks
12:23:29 <gillliard> We've got a really big agenda today - should we move on?
12:23:34 <gillliard> ;)
12:23:38 <alex_xu> ok, no problem
12:23:53 <alex_xu> next one is Remainging policy moving to API layer
12:24:08 <alex_xu> I think this is say the policy clean up patches
12:24:23 <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:24:35 <gillliard> Is that the final set of patches alex_xu ?
12:24:41 <johnthetubaguy> there is a lot more to it though, although those patches are the first step
12:24:49 <alex_xu> gillliard: yes
12:25:04 <johnthetubaguy> we were talking about defaults in the code, and renaming policy so it matches the URL node the code
12:25:31 <johnthetubaguy> and looking at clean hierarchies, and possible some level of split up admin
12:25:47 <johnthetubaguy> now we might want to push that all out until M, so we get the docs done
12:26:16 <johnthetubaguy> ...but I worry about Liberty going out without those updates, given the upgrade pain after than change
12:26:29 <bauwser> +1 to the docs saying "please don't confuse RBAC roles with context admin" :)
12:26:36 <johnthetubaguy> sdague was talking to the keystone folks about some of those changes
12:26:47 <johnthetubaguy> bauwser: true, there is that as well
12:27:15 <johnthetubaguy> I have a TODO to write up that conversation, but I am waiting until Monday before I look at those action items for me
12:27:26 <johnthetubaguy> well someone has a TODO anyways
12:27:50 <alex_xu> TODO for those policy works?
12:28:56 <alex_xu> emm...let's move on
12:29:13 <alex_xu> the last one "Middleware to relax jsonschema validation on v2.0"
12:29:20 <gillliard> #link https://review.openstack.org/#/c/173243/12/specs/liberty/approved/api-relax-validation.rst,cm
12:29:56 <alex_xu> sdague said the plan for this is changed in the summmit, but review it today, I think the spec already updated to the new plan
12:30:27 <alex_xu> one thing I confuse, why we must need middleware
12:30:31 <bauwser> alex_xu: the spec was merging 2 concerns IIRC
12:30:53 <bauwser> alex_xu: 1/ relax validation for headers not providing version
12:31:07 <bauwser> 2/ drop support for headers providing version if v2
12:31:07 <johnthetubaguy> yeah, its probably two things in there
12:31:15 <johnthetubaguy> I updated it post summit
12:31:22 <johnthetubaguy> I probably lost some of the detail though
12:31:26 <bauwser> both can be done in the same middleware that said
12:31:49 <alex_xu> middleware need for figure the request coming from which endpoint?
12:31:54 <johnthetubaguy> so its middleware because it only applies to /v2.0 and not /v2.1
12:31:59 <bauwser> alex_xu: to the question whether a WSGI middleware is a good option, +1 to that
12:32:03 <johnthetubaguy> alex_xu: that was the idea
12:32:35 <johnthetubaguy> there could well be a better way, but the proposal at the summit was for middleware
12:32:39 <alex_xu> johnthetubaguy: the request object can get the url, and we check is coming from '/v2' or '/v2.1'
12:32:40 <johnthetubaguy> so I included that in the spec
12:32:52 <bauwser> alex_xu: honestly, I don't like it
12:32:57 <johnthetubaguy> alex_xu: so this code is only allowed to apply to /v2 and not v2.1
12:33:03 <alex_xu> bauwser: why?
12:33:04 <bauwser> alex_xu: I mean the request check directly in the codepath
12:33:25 <gillliard> I suggest leaving middleware-or-not question to implementation.
12:33:29 <bauwser> alex_xu: because that's contextually something that can be done *before* handling the request :)
12:33:33 <gillliard> ie remove from spec
12:33:45 <johnthetubaguy> gillliard: agreed, but theres an important issue behind it
12:33:50 <johnthetubaguy> so the thing we need to agree is
12:33:52 <bauwser> gillliard: well, this is not an implementation detail IMHO
12:34:07 <johnthetubaguy> v2.1 stays the same
12:34:21 <johnthetubaguy> v2.0 has the relaxed validation
12:34:26 <alex_xu> bauwser: but the jsonschema validation is exected in the code path
12:34:36 <johnthetubaguy> v2.0 throws errors should no version header be sent
12:34:46 <bauwser> johnthetubaguy: maybe you could drop mention of the version check for v2.0 ?
12:34:56 <johnthetubaguy> that happens with both the v2 and v2.1 code behind it
12:35:01 <bauwser> johnthetubaguy: and put it in a separate spec ?
12:35:04 <johnthetubaguy> bauwser: its in there
12:35:11 <bauwser> johnthetubaguy: I know
12:35:23 <bauwser> anyway, let's discuss that on the spec
12:35:30 <alex_xu> agree
12:35:34 <johnthetubaguy> bauwser: so I think we need both to solve the described problem
12:35:40 <bauwser> agreed
12:35:59 <johnthetubaguy> the spec is about resolving a problem, hence its grouped together
12:36:20 <johnthetubaguy> anyways, I am open to other options, lets discuss those on the spec I guess
12:36:34 <johnthetubaguy> or just after the meeting in #openstack-nova if that works for folks
12:36:40 <bauwser> +1
12:36:42 <gillliard> sure
12:36:46 <alex_xu> +1
12:36:52 <alex_xu> For the priority items,  there already have nova-spec list out by johnthetubaguy
12:36:57 <alex_xu> #link https://review.openstack.org/187272
12:37:20 <alex_xu> hope people review it
12:38:03 <alex_xu> And we have a powerful list
12:38:10 <alex_xu> #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
12:38:19 <alex_xu> List some patch need core team review, and the patch should have team member +1 at least.
12:38:51 <alex_xu> Currently the list is emptly, looks like wasteful :)
12:39:47 <alex_xu> Any more question for this topic?
12:39:52 <johnthetubaguy> alex_xu: so the hope is the sub team decides its "ready" somehow
12:40:11 <johnthetubaguy> and if that becomes a good enough vote, it might eventually become a +2
12:40:25 <johnthetubaguy> might want a second list, please subteam review these patches
12:40:35 <johnthetubaguy> I maybe over loading those two things
12:40:43 <bauwser> hence why it's not a list of Xmas gifts, but rather something you want to port to cores for merges
12:40:44 <alex_xu> yea, sdague suggest our folks discuss priority items early next week
12:40:46 <johnthetubaguy> (I plan to send an ML post to describe all this process on monday)
12:41:13 <alex_xu> bauwser: +1
12:41:44 <alex_xu> let's move on
12:41:47 <alex_xu> #topic Patch Review
12:42:03 <alex_xu> most of them mention previous topic
12:42:37 <alex_xu> There are some policy document up review, some of them I need update…
12:42:44 <alex_xu> #link  https://review.openstack.org/162912
12:42:51 <alex_xu> #link https://review.openstack.org/162913
12:42:58 <alex_xu> #link https://review.openstack.org/187896
12:43:56 <alex_xu> and other patch already metioned in previous topic: relax validation, microversion for python-novaclient
12:44:27 <alex_xu> and policy cleanup stuff
12:44:33 <alex_xu> so...let's move on
12:44:45 <alex_xu> #topic API-WG patches
12:45:05 <alex_xu> gillliard: Do you know what is going on 501 guideline, I'm think there patch is going to use 501. https://review.openstack.org/#/c/148509/
12:45:35 <gillliard> I think the API-WG needs prodding to make a statement one way or the other.
12:46:02 <gillliard> That's not the only patch which adds NotImplemented error
12:46:48 <gillliard> But this conversation has just stopped: https://review.openstack.org/#/c/183456/
12:46:50 <alex_xu> gillliard: the api-wg agree with Sean's propose?
12:46:59 <gillliard> no conclusion there
12:47:02 * alex_xu didn't get chance follow that
12:47:17 <gillliard> #action (gilliard) re-start 501 conversation with api-wg
12:47:25 <alex_xu> gillliard: thanks
12:47:28 <gillliard> We have a few patches which depend on it...
12:47:55 <alex_xu> gillliard: yea, block people will feel angry :)
12:48:16 <gillliard> Are people using APIImpact enough in Nova?
12:48:30 <gillliard> and, is that actually getting us useful feedback from the api-wg?
12:49:14 <alex_xu> gillliard: no guarantee, it also need depend on review notice people forget add flag
12:49:49 <alex_xu> gillliard: I didn't get your second question
12:50:37 <gillliard> The API-WG can search all of gerrit for APIImpact and provide feedback for us. But I don't think I've ever actually seen that happen.
12:50:57 <johnthetubaguy> so I think its more for our API group to see those changes
12:51:06 <johnthetubaguy> I am not sure API-WG will can all repos for API changes
12:51:16 <johnthetubaguy> s/can/scan/
12:51:28 <gillliard> Fair enough.  We can always take anything contentious to them directly anyway.
12:51:52 <gillliard> Anyway, moving on...?
12:52:23 <bauwser> +1
12:52:25 <gillliard> alex_xu has moved some of his nova devrefs to the api-wg repo
12:52:45 * alex_xu drop the network...
12:52:53 <alex_xu> gillliard: yea
12:53:03 <alex_xu> #link  https://review.openstack.org/187112
12:53:23 <gillliard> So the nova ones are abandoned?
12:54:54 <eliqiao> alex_xu just phone me that he has something problem with the network, gillliard, can you please go on ?
12:55:06 <gillliard> :(
12:55:18 <bauwser> #chair gillliard ?
12:55:22 <gillliard> The other one he moved over is...
12:55:25 <gillliard> #link https://review.openstack.org/#/c/187896/
12:55:47 <gillliard> Let's see....
12:56:00 <gillliard> Please review those if you feel you can
12:56:05 <gillliard> #topic open discussion
12:56:18 <gillliard> (doesn't work)
12:56:37 * alex_xu back again...offline any time
12:56:43 <alex_xu> #topic open discussion
12:56:53 <alex_xu> #link https://bugs.launchpad.net/nova/+bug/1426241
12:56:53 <openstack> Launchpad bug 1426241 in OpenStack Compute (nova) "pci plugin needs to be re-enabled for V2 microversions" [Medium,Confirmed] - Assigned to Yongli He (yongli-he)
12:57:03 <bauwser> alex_xu: could you please #chair gillliard ?
12:57:19 <bauwser> alex_xu: in case of any internet issue coming back
12:57:56 <gillliard> So, about that bug. I wasn't sure if it was still valid or not.  No big deal I guess.
12:58:17 <alex_xu> #chair gillliard
12:58:18 <openstack> Current chairs: alex_xu gillliard
12:58:23 <gillliard> If anyone has an opinion they can comment directly on the bug
12:58:28 <gillliard> (thanks alex_xu)
12:58:35 <alex_xu> that one heyongli is working on
12:58:48 <alex_xu> I have confirm with him
12:59:07 <gillliard> OK thanks. The other thing is that sdague wrote something very nice
12:59:22 <johnthetubaguy> that API changes looks like it needs a spec
12:59:22 <gillliard> #link https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
12:59:32 <alex_xu> johnthetubaguy: yes, I told him
12:59:37 <johnthetubaguy> alex_xu: cool
13:00:07 <gillliard> I think we should share that blog post widely, and solicit feedback. Understanding the API is a big hurdle for many people I think.
13:00:16 <gillliard> I mean, it's quite complicated...
13:00:21 <bauwser> gillliard: sdague already shared it to the ML
13:00:33 <gillliard> awesome.
13:00:36 <alex_xu> should we reference that blog link in the devref?
13:00:47 <gillliard> I think devref should stand alone.
13:00:57 <gillliard> That content will move into a devref at some point I think.
13:01:08 <alex_xu> ok
13:01:21 * gillliard looks at his clock
13:01:47 <bauwser> #endmeeting ? :)