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