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