13:00:07 #startmeeting nova api 13:00:08 Meeting started Wed Mar 29 13:00:07 2017 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:11 The meeting name has been set to 'nova_api' 13:00:18 who is here today? 13:00:41 o/ 13:00:41 o/ 13:00:49 o/ 13:00:52 \o 13:00:59 * johnthetubaguy although is on a hangout with sdague right now 13:01:16 #topic priorities 13:01:40 johnthetubaguy: it is good for ask sdague join the meeting after hangout :) 13:01:54 #link https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/policy-docs 13:02:03 good progress on policy doc ^ 13:02:22 yea very nice 13:02:46 thanks for OSIC guys and Kevin_Zheng 13:03:19 #link https://review.openstack.org/#/c/433037/ 13:03:26 o/ 13:03:41 the spec for remove scope check is updated 13:03:45 yea thanks Kevin_Zheng and OSIC 13:03:53 but I didn't revisit it yet 13:04:08 johnthetubaguy: do you have anything want to talk about that? 13:04:12 more eyes on both of those specs would be great 13:04:20 not really, honestly 13:04:30 ok 13:04:46 * gmann will read tomorrow. 13:05:12 #link https://review.openstack.org/445864 13:05:33 ^ the poc of remove stevedore updated, and i got all the tests passed \o/ 13:06:00 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-no-more-extensions-pike 13:06:08 this is all the patches ^ 13:06:21 #link https://etherpad.openstack.org/p/api-no-more-extensions-pike 13:06:34 ^ and write the plan down to the etherpad 13:07:14 alex_xu: looked on all series and it looks fine to me. i will review those thoroughly tomorrow. 13:07:24 gmann: thanks 13:07:46 the plan is reverse than the original one of the bp 'api-no-more-extensions' 13:08:00 alex_xu: hope we all agree on etherpad plan before we start working on those. I am with you on that plan. 13:08:08 alex_xu: yea. 13:08:31 johnthetubaguy: sdague may confirm the go ahead 13:09:06 not sure what you mean by the reverse plan? 13:09:07 The plan is removing the stevedore first, then merge the extended controllers into the main controllers. 13:09:12 ah 13:09:47 the items #1 to #4 is about removing stevedore. 13:09:58 yea spec said, merge extension first then stevedore in last 13:10:01 so there are two types of the extended controllers 13:10:05 the items #5 to #8 is about cleanup 13:10:20 there are single API enpoints that are extended, I would squash those first 13:10:28 like adding attributes into an exiting API via an extension 13:10:47 johnthetubaguy: yes 13:11:07 I don't really mind which way we attack it honestly 13:12:37 #link https://review.openstack.org/#/c/445864/7/nova/api/openstack/compute/routes.py@69 13:12:54 ^ here the list all the controller for servers 13:13:32 alex_xu: johnthetubaguy i think we can merge those soon but i am worried about 3rd can take time ? 13:14:00 I thought if we merge the controller first, I feel we will need to wait a long time to get the point of removing stevedore 13:14:16 so what causes us, or operators the biggest pain right now 13:14:21 could we do that bit first? 13:14:47 remove the stevedore, totally disable the extension? 13:15:13 stevedore will cleanup lot of thing from operator side, like lot of unnecessary policy, entry points etc 13:15:35 and extension code merge is good from developer point of view 13:16:34 OK, so it feels like we have the order correct then, fixing stuff from operator and removing the extension-ey-ness for real 13:16:41 so my opinion is same as alex_xu , to kill the stevedore first 13:16:46 yea 13:17:24 yea, code merge is really about cleanup 13:18:46 I should move #6 to the last one 13:19:18 alex_xu: yea, json schema would be nice to do before that and server create 13:19:46 gmann: yea, and json-schema extension point really make the code complex 13:20:19 and error prone when any microversion need to change he schema which are extended in many place 13:20:30 gmann: agree 13:21:27 and I need help on the #3, there probably need few patches 13:21:48 alex_xu: i will help on that. 13:22:02 gmann: thanks a lot 13:22:03 i would love to 13:22:09 oh, hey, sorry just saw thius 13:22:10 Kevin_Zheng: thanks :) 13:22:17 not to derail this debate, but did we put this as higher priority that the API concept guide finishing off bits? 13:22:21 i will be doing more Nova things for next 3 week at least with leaving my internal work on low priority :) 13:22:27 alex_xu: honestly, whatever way you want to do the tear down I'm good with 13:22:40 sdague: cool 13:23:04 johnthetubaguy: I think it's probably worth cleaning up the code here, we've had quite a lot of focus on the english content, and mentally it probably makes sense to do some code scrub for a while to get people energized again 13:23:10 deleting code is always energizing 13:23:18 johnthetubaguy: i think yes but concept guide should be high? 13:23:31 sdague: that totally fair 13:23:49 this is all good stuff that needs doing, for sure 13:24:09 plus the code scrub ends up with more eyes in the code during writing and review, so it's a bit of a refresher about how things actually work 13:24:21 yeah, thats no bad thing 13:24:25 because, there are still things that surprise me :) 13:24:29 +1 13:24:54 yea 13:26:02 * bauzas waves late 13:26:32 johnthetubaguy: sdague bauzas something ready to review https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-no-more-extensions-pike 13:26:37 johnthetubaguy: sdague ll plan concept guide work also and hope we finish good amount in Pike if not complete 13:26:49 here is the first patch https://review.openstack.org/#/c/450830/ 13:26:52 alex_xu: ++, will doo 13:27:00 bauzas: thanks 13:27:10 alex_xu: cool, I'll put it on my review queue for this afternoon 13:27:34 gmann: thanks 13:27:37 sdague: thanks 13:28:32 ok, that is all for prorities I think 13:28:40 #topic open 13:29:35 sdague: Matt asks about nova-api via apache thing, but I rememeber we didn't reach that one in last meeting, not sure whether he reach to you 13:30:08 there was some work dansmith was going to do on that around reporting service versions, I think 13:30:39 yea, remeber there is a bug relate to that 13:31:03 johnthetubaguy: I wasn't going to but someone was yeah 13:31:40 that sounds like the main blocker, but I can't say I have tried it out myself 13:32:19 yeh, and honestly I wanted to get this uwsgi stuff sorted in devstack before cutting over anyway 13:32:28 because the logging / debug story is much better 13:33:04 ah, cool, that makes sense 13:33:40 devstack will support both uwsgi and apache? or just uwsgi? 13:35:45 ok... let us move on 13:35:51 edleafe: your turn 13:36:16 ok, I've written it up in a BP: https://blueprints.launchpad.net/nova/+spec/remove-openstack-api-directory 13:36:55 The question is: do we need the nova/api/openstack directory, or could we simplify that to nova/api? 13:37:39 It does involve mostly search-and-replace code changes, but there will be changes to api-paste.ini, too 13:37:55 mriedem wanted to get your input before approving 13:37:57 edleafe: I prefer to look at after https://etherpad.openstack.org/p/api-no-more-extensions-pike 13:38:02 so api-paste.ini has be backwards compatible I think, but thats possible 13:38:30 I have some WIP code to show what's involved: series starting with https://review.openstack.org/#/c/444521/ 13:38:40 Super-low priority, of course 13:39:22 its tempting doing that when we are all in person, at some later date 13:39:36 it was quite disruptive doing the other renames before 13:40:11 its at least not miss-leading like the other directory names are, so it not as urgent 13:40:11 johnthetubaguy: yes, especially since it would involve many patches 13:40:27 Unless you have one giant, unreviewable patch :) 13:40:27 s/are/were/ 13:40:35 yea any harm if we keep that 13:40:58 misleading in the sense that there should be more than one nova API 13:41:17 edleafe: before it say v3, but really it didn't mean that, etc 13:41:22 and contrib, etc 13:41:41 there are all openstack apis in there, so it doesn't seem too missleading 13:41:44 if a bit confusing 13:41:47 johnthetubaguy: agreed. Very confusing to new devs working with the code 13:42:21 I am not sure its "very" certainly a bit confusing 13:42:32 I meant the v3 examples 13:42:36 ah, yeah 13:42:44 that stuff was terrible 13:42:50 * edleafe loves async conversations 13:42:55 I would be tempted to leave it for now, its kinda disruptive 13:43:25 yea me too, we can iterate later on this may be next cycle 13:43:30 the other things we have in flight have more value I think, so I don't really want to disrupt all those right now 13:43:38 Sure - like I said, super-low priority 13:43:50 This was the result of conversations at PTG 13:44:29 ok 13:44:42 anything more want to bring up? 13:44:47 I'm not sure whether metadata API is also handled here, but maybe I can get people interested in giving feedback on the changes suggested in https://bugs.launchpad.net/nova/+bug/1676363 and the related patchseries 13:44:47 Launchpad bug 1676363 in OpenStack Compute (nova) "The network metadata should be more useful" [Medium,In progress] - Assigned to Dr. Jens Rosenboom (j-rosenboom-j) 13:45:20 frickler: there was a lot of talk with getting neutron controlling all that information 13:45:52 now if there are some quick non-impacting wins thats totally worth considering 13:46:14 IMO for IPv6 current state is unuseable 13:46:33 so it should not have any negative impact 13:46:48 frickler: mmm, I do remember some bug I triaged that was related 13:47:02 for ipv6 and metadata I mean 13:47:04 lemme find it 13:49:00 frickler: ah, so no structural change here, just outputting more correct info I guess? 13:49:09 mmm, can't find the bug 13:49:52 johnthetubaguy: mostly, yes. 13:50:36 johnthetubaguy: changing the type from ipv6_dhcp to something else is strictly speaking an incompatible change 13:51:20 but it can only lead to broken setups currently anyway 13:51:57 so the versioning of that bit of the API is a little strange, I would need to go remember how we do things in there 13:52:10 it feels like most of these changes would all get added as a new version 13:52:28 or rather, should get added as a new version 13:52:37 so consumers can opt in to use the newer version, if its present 13:53:49 yes, that would be the more conservative approach 13:54:34 I don't 100% remember how that works for network.json right now 13:54:42 I know we do that for a few of the other files already 13:55:15 would be a bit difficult because the subnet type is generated on the compute node and pushed into the instance cache from there 13:56:19 hmm, would have to convert on the other side, yes 13:56:23 * alex_xu reminds 4 mins left 13:56:28 but o.k., I'll try to look into how this versioning code works 13:58:28 johnthetubaguy: sdague gmann free to run the meeting next week. I will begin PTO from this friday, and it's about whole next week. 13:59:02 ah, have a good break! 13:59:04 anything more want to bring up, 2 mins left, otherwise, I will close the meeting 13:59:07 alex_xu: sure, i can run 13:59:14 johnthetubaguy gmann thanks 13:59:27 #endmeeting