13:02:56 #startmeeting nova-api 13:02:57 o/ 13:02:57 Meeting started Wed Jun 15 13:02:56 2016 UTC and is due to finish in 60 minutes. The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:01 The meeting name has been set to 'nova_api' 13:03:04 o/ 13:03:18 o/ 13:03:20 o/ 13:03:23 #link https://wiki.openstack.org/wiki/Meetings/NovaAPI 13:04:08 notes from last meeting - http://eavesdrop.openstack.org/meetings/nova_api/2016/nova_api.2016-06-08-13.00.html 13:04:37 we have one action from last meeting about alex_xu deleting user_id items from docs for policy, but I guess we'll come back to it next week 13:04:44 o/ 13:04:47 I'll reaction that for it to be on next week's cycle 13:04:57 #action alex_xu to update policy docs to remove user_id references to server actions 13:05:10 #topic API priorities 13:05:34 api-ref status - http://burndown.dague.org/ - about the same as last week 13:06:00 I know I ended up more in specs land around some of the deprecations and removes 13:06:23 it would be good to try to get some more review there though, there are still quite a number of patches outstanding 13:06:41 any other api-ref updates or questions from folks? 13:07:22 ok, policy... 13:07:47 the oslo.policy release with the infrastructure happened 13:07:58 so now this is all back on the Nova side 13:08:20 does anyone have links to those patches? (I've not caught up with them yet) 13:08:46 I did have, I can't find them now, looking 13:09:02 https://review.openstack.org/#/c/329122/4/nova/policy.py 13:09:38 https://review.openstack.org/#/q/topic:bp/policy-in-code 13:09:39 or https://review.openstack.org/#/q/topic:bp/policy-in-code 13:09:45 i win! 13:09:50 mriedem: \o/ 13:09:54 :) 13:09:55 heh 13:10:00 https://review.openstack.org/#/q/topic:bp/policy-in-code+project:openstack/nova+status:open 13:10:05 more specifically 13:10:22 ok, cool. looks like some pep8 issues up the stack. but those would be good to review 13:10:47 yeah, thats looking way more like what I was expecting since I last hit those patches 13:10:56 that bottom patch is pretty damn big 13:10:56 johnthetubaguy: great 13:11:06 i haven't gone through it yet so don't know how mechanical it is 13:11:34 but i expected the policy conversion to be more like the api-ref conversion a big 13:11:38 extension by extension 13:11:45 s/big/bit/ 13:12:05 yeh, maybe we could get claudio_ to split up that first patch into a couple easy single extension ones to see how it all looks 13:12:22 wrapping your head around the big one first is hard 13:12:23 +1 on splitting it up 13:12:56 does someone want the todo to chat with claudio_ on that? 13:13:02 i can 13:13:05 i just commented on the change 13:14:03 #action mriedem to follow up with claudio on splitting up policy patch for easier review 13:14:06 ok, great 13:14:53 on the API deprecate / remove front 13:15:27 we approved a spec discussing the extension removal - https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html 13:15:37 which has also been posted to the dev and ops lists 13:16:00 orly 13:16:02 didn't see that 13:16:07 the ML i mean 13:16:20 ah i see it 13:16:33 http://lists.openstack.org/pipermail/openstack-dev/2016-June/097285.html 13:16:37 no replies 13:16:39 funny 13:16:39 nope 13:16:53 at this point, I feel we're pretty covered on communication 13:17:06 as we have a quite detailed document with reasoning 13:17:27 and have pushed it out on multiple channels 13:17:28 yeah, it seems good to me 13:18:03 https://review.openstack.org/#/q/topic:fold_disk_config is most of the removal of the os-disk-config extension (working on the image extends right now to fully remove it) 13:18:22 for some reason gerrit didn't change the topics with the blueprint name 13:19:00 nice. 13:19:16 that will hopefully create a pattern for doing future ones 13:19:33 I think doing the "show" patch separate from "create" patch is useful 13:19:34 yeah, I plan to follow it and add some ... 13:20:01 it makes it a little simpler to review, because one is down in the views/ directory, and the other is in servers.py 13:20:50 sdague: yea, that is much easy to review and after all SHOW, UPDATE, REBUILd extension file can go away 13:21:00 https://review.openstack.org/#/c/329549/1/nova/api/openstack/compute/servers.py@58 is one of the things to consider 13:21:39 we basically will end up with a translation function between REST API and internal attributes, which is fine, but if we want it in servers.py or in some other utils.py for some of these conversion functions 13:22:24 gmann_: yeh, once the create, update, rebuild extensions go away, that code becomes so much easier to understand 13:23:12 yea 13:23:25 ok, please review those, lets build a pattern, then we can get more of them up there 13:23:56 #info https://blueprints.launchpad.net/nova/+spec/api-sample-tests-with-all-extensions completed 13:24:01 thanks gmann_ for that 13:24:20 yea, that was on hold so long 13:24:26 that makes the extensions infrastructure tear down possible 13:25:03 any other items on the v2 / extensions tear down? 13:25:56 ok, let's go to open discussion 13:26:01 #topic Open Discussion 13:26:08 sdague: one on proxy deprecation 13:26:15 gmann_: go for it 13:26:21 started with APi doc update 13:26:23 #link https://review.openstack.org/#/c/329357/ 13:26:59 i question that can we make os-assisted-volume-snapshots also in this list? 13:27:06 actually did not find it in spec 13:27:14 gmann_: that works on servers 13:27:17 so we don't deprecate that one 13:27:22 it's an odd case 13:27:26 only supported by libvirt i think 13:27:48 yea, and snapshot as QCOW2 file 13:28:10 we should probably document the limitations of the API 13:28:14 and store the snapshot status on cinder side so was just wondring, if all can be own by cinder 13:28:16 but, yes, it's an action on servers 13:28:28 so... it doesn't really fit, right? 13:28:46 not it's an action on a server resource 13:28:48 so not a proxy 13:28:53 s/not/no/ 13:28:56 right 13:29:03 but yeah we should doc that it's only supported by libvirt 13:29:10 ohk, we can add that 13:29:32 i have .inc patch for that, ll update. 13:29:32 #action someone to document that os-assisted-volume-snapshots is only implemented by the libvirt compute driver 13:29:42 #undo 13:29:49 mriedem: o/ 13:29:49 #action gmann to document that os-assisted-volume-snapshots is only implemented by the libvirt compute driver 13:29:58 great 13:30:16 isn't that the one that really is only called by cinder? 13:30:58 johnthetubaguy: that would be swap_volume 13:31:01 it is admin only 13:31:04 unless there is more than one 13:31:11 no, I think its when you do "local" volumes? 13:31:12 "os_compute_api:os-assisted-volume-snapshots:create": "rule:admin_api", 13:31:12 "os_compute_api:os-assisted-volume-snapshots:delete": "rule:admin_api", 13:31:32 you know, I so wish we had specs back when all these random things were added to the API 13:31:39 so we've have any idea why people wanted them :) 13:31:46 cinder does call it 13:31:54 also this API is very odd in point of request/response 13:32:27 it take snapshot_id and id in request and return 'id' which is not used 13:32:30 the remotefs volume driver in cinder calls the nova api from it's _create_snapshot_online method 13:32:46 oh... this is the thing to deal with glusterfs? 13:33:00 delete happens on file name base so not sure how to document that 'id' :) 13:33:05 I thought it was just local qcows really, but I could be remembering this wrong 13:33:10 because snapshots don't work in the expected way there? 13:33:29 ok, I think we probably have a todo to figure out where and why this is called and update the docstring - https://github.com/openstack/nova/blob/56dce766d8f367647ceae4b35885bcedc9d57663/nova/api/openstack/compute/assisted_volume_snapshots.py#L36 13:33:29 yea glusterfs 13:33:53 all that detail probably doesn't need to be in api-ref, but it should at least be in the code 13:34:06 plus, 13:34:09 like swap volume 13:34:15 i'm sure this isn't integration tested today 13:34:19 right 13:34:31 * mriedem feels like starting a dev list thread 13:34:36 yea 13:34:38 mriedem: feel free 13:35:14 right, there no tempest tests here for sure 13:35:39 sdague: yea there is no 13:35:43 I do kind of wonder if the long term evolution here is using the admin events from cinder -> nova instead of a top level API call 13:35:54 but that's kind of noodling about futures 13:36:06 ok, so coming back to concrete things. 13:36:20 we should review gmann_'s patch https://review.openstack.org/#/c/329357/ 13:36:28 mriedem: are you going to start a thread around this? 13:36:33 sdague: yeah 13:36:37 give me an action item 13:36:48 #action mriedem to start openstack-dev thread on os-assisted-volume-snapshots 13:36:52 sdague: and after the doc one, we need microversion to return 404 on those proxy 13:37:04 sdague: you are planning to bump that or shall i start? 13:37:07 gmann_: right, are you up for doing that microversion change? 13:37:17 sure 13:37:22 gmann_: I've got a pretty full plate, if you could run with it that would be great 13:37:46 #action gmann_ to write microversion change for 404 on API proxies 13:37:53 yup 13:37:58 great 13:38:12 thats all on this from my side 13:38:14 great 13:38:22 anyone else with topics for open discussion? 13:40:33 going once... 13:40:49 oh... wait, there is something else we should bring up 13:41:08 #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/097349.html 13:41:16 [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing 13:42:00 this is specifically about defcore testing of the Nova API and changes to Tempest to provide the possibility of relaxing strict response checking for some period of time 13:42:22 as it is specifically about the Nova API, it is probably worth having Nova folks voice their view point there 13:42:25 some period of time? 13:42:33 or they want for always 13:42:41 until the 2017.01 defcore guidelines 13:42:48 ahh 13:43:10 hogepodge's proposal is pretty detailed 13:43:25 I think I'm the only Nova team member that's weighed in so far 13:44:35 so that would be good to consider, and voice an opinion if you have one 13:45:13 johnthetubaguy: I think your pov would be especially useful, though I realize you are on multiple sides of this fence 13:45:33 ok, anything else from folks? 13:46:05 hi, sorry, got cut off there 13:46:06 I am still thinking about it 13:46:11 the problem for me is the experimental tag has been taken off the new spec for the version header 13:46:40 it would be nice if we could have experiemental suff people opt into, while we are getting that upstream and proving it out 13:47:12 johnthetubaguy: do you have specific instances of that? 13:47:24 otherwise, the transition period makes a lot of sense to me, to take the sting out of this (largely accidental) defcore test change 13:47:32 I feel like a lot of the time this got discussed in the abstract 13:48:09 so, there is a spec we didn't get merged around scoped server groups, it would be nice to test out some of that with customers, using experimental API you explicitly opt into 13:48:13 and it's easier for me to understand why a vendor would add content to 'server: {}' before taking it upstream if I see a concrete example 13:48:48 johnthetubaguy: ok, though in those cases it's extra resources right, not changed ones? 13:49:16 hmm, changed ones 13:49:23 but at least you opt in via a header 13:49:42 and then you write a new client library to support them? 13:50:19 I guess it feels to me that A/B testing really doesn't work with software APIs. You have to just commit to release, and update it over time 13:50:29 possibly, yeah 13:50:42 so then it can go out with header right? insted of in response dict 13:50:50 well, this is "unsupported" API we don't tell folks about, unless they find them, that will get ripped out once completed 13:51:42 johnthetubaguy: so, why not make it on a different endpoint? 13:52:14 well for long lived stuff totally 13:52:21 I just don't believe once anything is in it's ever getting deleted 13:52:26 this is more a one off thing, to try a slighly change out 13:52:34 that's been my issue with "experimental" 13:52:45 you'll have a customer that now depends on it 13:52:48 you aren't going to remove it 13:53:00 yeah, it might only be available like that on a separate end point 13:53:20 so we would tell then to transition, and be upfront about it going away at the beginning, its quite high touch 13:53:38 but yeah, I get your point, the transition is bumpy, for sure 13:53:58 at least its clear its rackspace specific, if you have to opt into it 13:54:08 I need to think about this some more, as you can tell! 13:55:05 ok, anything else from folks? 13:56:09 alright, lets call it a wrap 13:56:13 #endmeeting