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