13:02:13 <sdague> #startmeeting nova-api
13:02:14 <openstack> Meeting started Wed Jul 27 13:02:13 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:02:19 <openstack> The meeting name has been set to 'nova_api'
13:02:31 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/NovaAPI
13:02:39 <gmann_> o/
13:03:21 <woodster_> o/
13:03:22 <sdague> ok, I'm still catching up on where things stand. Let's do this quickish.
13:03:29 <sdague> #topic API priorities for Newton
13:03:56 <sdague> #info API proxy deprecation landed as mv 2.236
13:04:01 <sdague> #info API proxy deprecation landed as mv 2.36
13:04:17 <gmann_> great things :)
13:04:40 <johnthetubaguy> 2.236 I thought I was transported to the future for a moment
13:04:51 <sdague> we decided that we'd only land 2 more mv this cycle, get me a network as 2.37, and there is a bug fix for 2.38 that ed was working on
13:05:41 <sdague> https://etherpad.openstack.org/p/nova-newton-midcycle @ L393
13:05:52 <sdague> were all the notes from the mid cycle there
13:06:08 <sdague> I started striking out things that are done
13:06:27 <sdague> so we also have gmann_'s image ref fix - https://review.openstack.org/#/c/338802/
13:06:54 <sdague> gmann_: is that ready now?
13:07:09 <johnthetubaguy> its adding a microversion still
13:07:18 <gmann_> sdague: yea, i need to update that to make more changes, to remove more stuff on uuid fetch from url
13:07:24 <sdague> ah, ok, we should get rid of that part
13:07:35 <gmann_> johnthetubaguy: i removed that but need more changes as we clean up this as bug
13:07:40 <johnthetubaguy> I think just landing the validation is worth while, we can follow up with the other bits
13:07:46 <gmann_> sdague: johnthetubaguy i will do that on tomorrow.
13:07:50 <sdague> gmann_: sounds good
13:08:00 <gmann_> johnthetubaguy: ok, i am ok with that way also.
13:08:12 <gmann_> johnthetubaguy: or just wait till tomorrow :)
13:08:31 <johnthetubaguy> yup, getting it all tomorrow is cool :)
13:08:46 <sdague> to follow on with the proxy item before, dansmith is working on the novaclient changes for the CLI, the first pass yesterday looked like a reasonable direction
13:08:46 <gmann_> yea, it will cleanup sample files also
13:08:58 <sdague> https://review.openstack.org/#/c/347514/
13:09:51 <sdague> the last fully uncovered bit for the API this cycle is - https://review.openstack.org/#/c/324068/
13:10:02 <sdague> which is the user_id policy enforcement
13:10:31 <sdague> jichen had some bug fix code around that early on, I'm hoping we can revive that and run with it.
13:10:34 <gmann_> sdague: 1 query on that, reboot is with user policy or without?
13:10:46 <sdague> I think we said no
13:10:55 <sdague> yeh, if it's not on that action list, then it's not
13:11:06 <sdague> https://review.openstack.org/#/c/324068/3/specs/newton/approved/user_id_based_policy_enforcement.rst@63
13:11:31 <gmann_> sdague: humm but reboot can be destructive sometime when server does not come up on reboot
13:11:34 <sdague> reboot is disruptive, it's not destructive
13:11:55 <sdague> gmann_: so can many other options
13:12:12 <johnthetubaguy> we want to kill this
13:12:14 <sdague> we're not trying to prevent every single way things can go wrong with servers
13:12:27 <sdague> right... this is intentionally not a complete answer
13:12:28 <johnthetubaguy> so I think supporting the minimum level of stuff makes sense here
13:12:34 <sdague> johnthetubaguy: ++
13:12:59 <johnthetubaguy> yeah, sends the right, we are helping while we transition you to something better message
13:13:03 <gmann_> sdague: yea if all fine but if someone else reboot and something happens wrong then it destruct the other VM
13:13:15 <sdague> gmann_: yep
13:13:36 <johnthetubaguy> thats intentional, its just a loose don't kill me separation
13:14:12 <johnthetubaguy> thing is, we could add reboot later, if that turns out to be the wrong place to put the line, but by that time we have a nice pattern, so it seems a good first stab at doing the minimum
13:14:16 <sdague> gmann_: the problem with that logic is all of a sudden then you have to start adding back in interface management, security group management, etc
13:14:29 <sdague> because all those things could make a server non responsive
13:14:38 <johnthetubaguy> sdague: +1 that list gets very big very quickly
13:14:47 <sdague> and we specifically said, this is not a complete solution
13:14:55 <gmann_> sdague: ahhh, yea even console etc also
13:14:58 <sdague> because we don't want people using this feature
13:15:14 <gmann_> hummm
13:15:22 <johnthetubaguy> I mean just doing it on delete is also another option, but I prefer this slightly more complete list
13:15:35 <sdague> the operators that weighed in on this found this to be enough for their needs
13:15:43 <johnthetubaguy> right, thats the key bit
13:16:00 <johnthetubaguy> the folks who have bit worries felt happy with this list
13:16:01 <gmann_> johnthetubaguy: sdague i see the point now.
13:16:03 <sdague> so, I think the list of actions is fixed
13:16:10 <sdague> it's just about implementation now
13:16:17 <gmann_> and if more action on demand we can add later
13:16:43 <sdague> gmann_: right, but we'll push back pretty hard
13:16:52 <gmann_> yes.
13:16:56 <sdague> because, again, this isn't an operating model we want to support
13:17:06 <gmann_> sdague: johnthetubaguy cool, Thanks for clarification.
13:17:11 <johnthetubaguy> I have asked the OSIC folks if anyone wants to take this, but I might just leave that for the backport
13:17:22 <sdague> johnthetubaguy: cool
13:17:55 <sdague> ok
13:17:56 <gmann_> i can also help
13:18:29 <gmann_> johnthetubaguy: you mean backport part can be taken by OSIC folks?
13:18:35 <sdague> gmann_: great, I've got my hands full on a few other things this week, so if you or anyone else can start in on the implementation, that would be great
13:18:49 <johnthetubaguy> gmann_: possibly, yes, at least I hope so
13:18:52 <gmann_> sdague: yea, i will start on that.
13:18:57 <sdague> gmann_: thank you
13:19:13 <gmann_> johnthetubaguy: cool, i will start and then backport can be helped by them
13:19:19 <johnthetubaguy> gmann: sounds good
13:19:21 <sdague> #action gmann_ to start on user_id policy patches
13:19:35 <gmann_> Thanks
13:21:22 <sdague> ok, policy in code....
13:21:38 <sdague> are there any updates or needs there, that one I'm not on top of atm
13:22:09 <johnthetubaguy> I haven't checked with claudio yet either
13:22:33 <sdague> ok
13:22:34 <johnthetubaguy> I think we agreed baby steps for next cycle, trying out a few existing operations to help the road to unblocking live-resize
13:22:53 <sdague> right, mostly i was wondering if there is anything outstanding for newton we need to land
13:23:18 <johnthetubaguy> there is an entry point from alaski
13:23:40 <johnthetubaguy> and possibly the nova-manage stuff to check against a specific user for their policy
13:23:51 <sdague> ok, do we have patches up?
13:24:12 <johnthetubaguy> there, were just hunting
13:24:37 <johnthetubaguy> https://review.openstack.org/#/q/topic:bp/discoverable-policy-cli,n,z
13:25:06 <sdague> ok, great
13:25:09 <johnthetubaguy> https://review.openstack.org/#/c/335667/
13:25:11 <gmann_> and some cli or tox env to generate the merged policy sample file with default and overridden rules
13:25:26 <gmann_> i remember we discussing the same in summit
13:25:37 <sdague> #action please review https://review.openstack.org/#/q/topic:bp/discoverable-policy-cli,n,z
13:25:58 <sdague> the last priority is api-ref - which we're now 75% done
13:26:13 <sdague> the plan is to do a final api-ref sprint post freeze
13:26:34 <sdague> so it doesn't distract during milestone 3
13:27:08 <gmann_> +1
13:27:16 <woodster_> sdague: so done for Newton RC?
13:27:20 <johnthetubaguy> sounds good
13:27:43 <sdague> woodster_: yeh, more or less
13:27:58 <sdague> because it's docs from master, it won't really be impacted by the freeze in the same way
13:28:13 <woodster_> sdague: nice
13:29:06 <sdague> ok, I think that's about it on priorities
13:29:11 <sdague> #topic Open Discussion
13:29:58 <sdague> any further topics that people want to discuss?
13:30:09 <gmann_> 1 i have
13:30:23 <gmann_> i am doing date-time strict checking in response schema o tempest side
13:30:25 <gmann_> https://review.openstack.org/#/c/304441/
13:30:45 <gmann_> to make sure we use same format for that in all APIs
13:31:01 <gmann_> but seems like Image API have different format in header
13:31:14 <gmann_> this failure- http://logs.openstack.org/41/304441/2/check/gate-tempest-dsvm-full/ca98815/logs/testr_results.html.gz
13:31:15 <sdague> the real image API, or our proxy?
13:31:23 <gmann_> ListImageFiltersTestJSON) tests
13:32:17 <gmann_> sdague:  list image, on nova side i think but need to dig the code
13:32:18 * mriedem joins late
13:32:45 <gmann_> should we fix it in those are image API at are deprecated ?
13:32:50 <gmann_> at> etc
13:33:07 <sdague> gmann_: well, honestly, we should probably make those tempest tests talk directly to glance instead of through Nova
13:33:30 <sdague> I don't think fixing the image proxy is really a thing we should do here
13:33:54 <gmann_> sdague: yea, that's what my thinking
13:33:54 <sdague> because it's likely to break people that depended on the old format, and it's deprecated
13:34:15 <gmann_> sdague: yea, we can loosen up the schema for that.
13:35:29 <gmann_> sdague:  as you pointed, should we change all image API call to glance on tempest ?
13:35:45 <gmann_> sdague: mean no proxy API use in tempest
13:35:53 <sdague> gmann_: I think long term Tempest needs to stop using proxy API calls
13:35:58 <sdague> because those are actually going away
13:36:26 <sdague> I don't know exactly how long that should be done over
13:36:41 <gmann_> sdague: humm.
13:36:48 <johnthetubaguy> yeah, its a trick one, but we need to move away from them
13:36:58 <mriedem> mtreinish brought up netwon-eol in the ML, but i don't think we want to wait that long
13:37:14 <johnthetubaguy> hmm, true
13:37:58 <gmann_> mriedem: ahh, because for stable branch they are not deprectaed?
13:38:20 <mriedem> gmann_: correct
13:38:21 <johnthetubaguy> I mean folks should have been deploying them for ages, but its not universally true I guess
13:38:51 <mriedem> if tempest.api.compute is calling volume or image proxies, i think that's a no brainer
13:38:54 <mriedem> to switch over
13:39:04 <mriedem> network gets trickier because nova-network wasn't deprecated until newton
13:39:11 <sdague> mriedem: yeh, mostly image proxy is the one that gets used a lot
13:39:20 <mriedem> but, i thought the tests in tempest were pretty well conditional on neutron being available or not
13:39:22 <gmann_> true
13:39:49 <mriedem> i joined late, is there a bug or something?
13:40:10 <sdague> gmann_ was trying to date validation schema in tempest
13:40:14 <gmann_> mriedem: not for that but we were discussing failure on date-time on https://review.openstack.org/#/c/304441/
13:40:18 <sdague> and the nova images proxy is inconsistent with the rest
13:40:25 <gmann_> yea
13:40:47 <sdague> and I think, we should leave it as known issue, and just get tempest not using those interfaces
13:41:08 <gmann_> sdague: +1.
13:41:26 <woodster_> Makes sense
13:41:33 <mriedem> hmm, we won't detect schema changes in the proxies if we do that, which is probably ok for master, but i worry about stable,
13:41:35 <mriedem> however,
13:41:43 <mriedem> anything changing the api in stable is rare
13:41:50 <sdague> right
13:42:13 <gmann_> mriedem: and that proxy API which deprecated and noted as critical bug fix only
13:42:28 <sdague> yeh, I think we're probably safe
13:42:36 <mriedem> gmann_: well it's deprecated as of 2.36
13:42:54 <mriedem> anyway
13:44:04 <sdague> ok, anything else from folks?
13:44:24 <johnthetubaguy> I am good, making some good progress
13:44:46 <gmann_> do we need to mention 2.36 on  api-ref for proxy API ?
13:44:58 <gmann_> or just current warning is ok
13:45:37 <sdague> gmann_: good point, we should probably update that as well
13:45:41 <mriedem> hmm, 2.36 would be more explicit
13:46:02 <sdague> honestly, I'm not going to fully think about information design on that after the freeze
13:46:15 <mriedem> " Warning These APIs are proxy calls to the Image service. Nova has deprecated all the proxy APIs and users should use the native APIs instead.  These will fail with a 404 after microversion 2.35. See: Relevant Image APIs. "
13:46:36 <gmann_> +1
13:46:58 <johnthetubaguy> Its tempting to leave all that till the doc sprint, but we do need something like that
13:47:28 <johnthetubaguy> I have a feeling we need some groupings in the doc, to make this all a bit clearer
13:47:41 <gmann_> johnthetubaguy: i can do quick update on this tomorrow
13:47:43 <mriedem> we have that in the rest api history doc
13:47:50 <gmann_> probably not leavign till doc sprint
13:47:53 <mriedem> i don't think we need to duplicate the rest api history doc in the api-ref
13:48:06 <sdague> yeh, I think that strategic grouping of things in the api-ref is going to help here
13:48:08 <mriedem> but adding something to the warnigns in the api-ref that these will fail after 2.35 is probably good
13:48:11 <johnthetubaguy> actually, we might, its different readers
13:48:21 <johnthetubaguy> yeah, that bit
13:48:24 <gmann_> yea
13:48:35 <mriedem> i thought we were going to move all of the proxies to the bottom?
13:48:42 <sdague> we did
13:48:44 <gmann_> mriedem: we did
13:48:46 <mriedem> can we just create a "Deprecated Proxy APIs" section?
13:48:55 <sdague> mriedem: there are many things we could do
13:48:56 <johnthetubaguy> yeah, thats what I am thinking
13:49:01 <gmann_> or Deprecated APIs
13:49:10 <johnthetubaguy> but feels like we can doc sprint that, else we will get distracted
13:49:13 <gmann_> having all deprecated API
13:49:19 <sdague> however, I think this is going to be a thing that is going to take trying 3 different things, seeing which is clearest
13:49:32 <sdague> and is going to be 2 dedicated weeks of trying and getting opinions
13:49:38 <sdague> which... we should do after freeze
13:50:11 <sdague> my experience on the api-ref things is the idea you have in advance, turns out to be completely confusing when you see it on the screen
13:50:22 <sdague> so you try a few things, and stare at them all
13:52:26 <sdague> ok, anything else?
13:52:39 <sdague> if not, lets get back to work :)
13:52:50 <sdague> #endmeeting