13:00:41 <alex_xu> #startmeeting nova api
13:00:42 <openstack> Meeting started Wed Aug 17 13:00:41 2016 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:45 <openstack> The meeting name has been set to 'nova_api'
13:00:47 <cdent> o/
13:00:59 <alex_xu> who is here today?
13:01:07 <edleafe> \o
13:01:30 <alex_xu> I start the meeting in a wrong channel again...
13:01:32 <sdague> o/
13:01:58 <alex_xu> ok, let us start the meeting
13:02:07 <alex_xu> #topic API Priorities
13:02:39 <jichen> o/
13:02:44 <alex_xu> sdague: what about the client for deprecation api?
13:03:36 <sdague> we've landed the 2 patches needed to talk to glance / neutron directly for name -> id lookup
13:04:02 <alex_xu> sdague: cool, the situation is really complex than what I thought...
13:04:04 <sdague> which is the prereq for not going to the network API
13:04:08 <sdague> yes
13:04:23 <sdague> the name -> id lookup was something we forgot was done at the CLI layer
13:04:37 <sdague> but, on the upside, that all seems to work
13:04:45 <alex_xu> cool
13:05:01 <sdague> the client patch that adds the nova network downgrade is posted, and I think close
13:05:23 <alex_xu> what means downgrade?
13:06:31 <sdague> if nova-net, all network calls are automatically made a 2.35
13:06:52 <alex_xu> sdague: ah, got it
13:07:53 <alex_xu> sdague: is that all about cli for deprecated api?
13:08:07 <sdague> https://review.openstack.org/#/c/347514/ - is the patch in question
13:08:13 <sdague> I guess it's still failing jenkins
13:08:21 <sdague> alex_xu: no, I think that's it
13:08:43 <alex_xu> sdague: there probably needs some patch for image and baremetal etc
13:09:22 <sdague> no, for those we just fail
13:09:41 <sdague> the point is that if you have a nova-network cloud, just failing network calls isn't an option
13:09:43 <alex_xu> sdague: yes, just fail
13:10:19 <alex_xu> sdague: the fail just make it return 404, or add decorator to limit the cli supported version?
13:10:26 <alex_xu> actually I mean the second one
13:10:56 <sdague> no, the idea is the client will just fail
13:11:06 <sdague> the 404 will pop back
13:11:15 <sdague> these have been deprecated for a while
13:12:08 <alex_xu> sdague: whether 404 confuse for user, this may not the fault of user, it is the fault for server side
13:14:26 <sdague> alex_xu: it might, but we've had deprecation here for a long time
13:15:31 <alex_xu> sdague: ok, so what about volume/fping, we say deprecate them before
13:15:51 <alex_xu> s/we say/we didn't say/
13:16:11 <sdague> I thought volume was basically already deleted
13:16:23 <alex_xu> ok
13:16:41 <sdague> I think this is the path we have. Client goes to freeze within 2 weeks
13:16:54 <sdague> if there are bugs we can fix them later as bug fixes
13:16:59 <cdent> people can always choose to use an older version
13:17:14 <cdent> (of the code, not microversion)
13:17:31 <cdent> we cater too much on this front
13:18:13 <alex_xu> cdent: ok
13:18:20 <alex_xu> good point also
13:18:57 <alex_xu> sdague: ok, just follow that plan
13:18:58 <edleafe> cdent: +1
13:19:38 <alex_xu> so let's move on?
13:20:00 * cdent nods
13:20:21 <alex_xu> for user_id based enforcement, we just left few patches
13:20:23 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/user_id_based_policy_enforcement
13:20:55 <alex_xu> sdague johnthetubaguy: have we said we will remove existed user_id support, and that not in the list?
13:21:07 <alex_xu> i remember we said leave it alone
13:21:46 * mriedem joins late
13:22:25 <alex_xu> mriedem: welcome
13:22:46 <alex_xu> mriedem: do you remember whether we said we will remove existed user_id support, and those check are not in the list?
13:23:02 <sdague> right, I think this is a little bit of a grey space.
13:23:10 <sdague> because we didn't know all of those when we did the spec
13:23:59 <sdague> so, I'll be honest, the thing I'd really like to see (in an ideal world) is a patch that warns if there is a user_id based polity for a policy point that doesn't support it
13:24:26 <sdague> so people that don't get the message via release notes would get it in their logs
13:25:10 <alex_xu> sdague: yea, that sounds nice for people
13:25:26 <sdague> alex_xu: we'd need someone to do it though
13:25:31 <alex_xu> note, we already merge one patch for remove user_id support...
13:26:01 <sdague> I suspect I'm pinned down on the client stuff this week, and next week is openstack east + ops summit, so I'll be out of a normal dev flow
13:26:19 <alex_xu> sdague: yes, I will take care those user_id based enforcment patches, gmann is not available in next one week or two.
13:26:32 <sdague> mriedem: opinions on the remove of existing user_id rules ?
13:26:43 <mriedem> i haven't followed that series at all
13:26:53 <sdague> mriedem: so, the question is
13:26:54 <mriedem> i thought the list of things from the spec was not meant to be comprehensive
13:26:58 <mriedem> but was signed off by ops
13:27:08 <sdague> we had a spec that said "we'll make these support this"
13:27:27 <sdague> then there was interpretation about "what about the places we already were doing this not in that list"
13:27:30 <alex_xu> sdague: we are lucky that patch merged failed
13:27:33 <alex_xu> #link https://review.openstack.org/#/c/354662/
13:27:48 <sdague> I'm fine not landing the removes
13:27:54 <mriedem> so server start
13:28:03 <mriedem> so the spec had a subset of destructive actions on a server
13:28:18 <mriedem> turns out there are already some places we allow this for other non-destructive actions, like starting a server
13:28:24 <sdague> right
13:28:31 <mriedem> so jim bob can start joe bob's server and now joe bob is getting billed
13:28:33 <mriedem> (maybe)
13:28:42 <sdague> joe bob isn't getting billed
13:28:48 <sdague> because usage is collected at a project level
13:28:50 <mriedem> and the question is, do we remove or just warn?
13:29:10 <sdague> the use case is catch all, don't care about utilization / quota for individuals
13:29:13 <mriedem> at this point in the cycle i'd rather just leave the functionality that's in place there
13:29:25 <mriedem> if we want to warn, whatever
13:29:39 <sdague> mriedem: right, so I agree probably don't rush this one
13:29:49 <sdague> mriedem: to be clear, my warn concern is not for these actions
13:30:11 <sdague> it's for policy points where they specify user_id, but we don't ever evaluate user_id
13:30:24 <mriedem> ok
13:30:26 <mriedem> that makes sense
13:30:30 <mriedem> +1 for that then yeah
13:30:41 <sdague> alex_xu: ok, so I think we don't do the removes
13:30:42 <mriedem> "you're doing something that isn't checked"
13:30:47 <alex_xu> sdague: yea, cool
13:30:50 <sdague> I -2ed the bottom patch
13:30:51 <mriedem> having a false sense of policy enforncement
13:30:59 <sdague> mriedem: right
13:31:14 <sdague> alex_xu: do you want to figure out if there is any reasonable way to do this warning before release?
13:31:22 <sdague> their may not be with the infrastructure we have
13:31:27 <alex_xu> sdague: yes, will do that
13:31:31 <sdague> but it would be good to investigate
13:31:47 <sdague> alex_xu: great, thank you
13:32:00 <alex_xu> #action alex_xu go to figure out if there is any reasonable way to do this warning before release
13:32:03 <alex_xu> sdague: np
13:32:18 <alex_xu> so we can move on?
13:32:25 <sdague> yes
13:32:36 <alex_xu> policy check cmd
13:32:38 <alex_xu> #link https://review.openstack.org/#/c/322944/
13:32:50 <alex_xu> I found it doesn't works for admin user
13:33:12 <alex_xu> do to we won't validate with keystone, then we don't know the role of user
13:33:26 <alex_xu> s/do to/due to/
13:34:01 <alex_xu> maybe two options: 1, validate with keystone, 2, user specific the role by cmd args
13:34:14 <sdague> alex_xu: well, we were sure it wouldn't be perfect
13:34:36 <sdague> honestly, I think I'd rather get this patch merged, and warn if you specify admin that this isn't accurate
13:34:42 <sdague> then figure out an admin path
13:34:52 <sdague> instead of not land anything
13:35:00 <alex_xu> sdague: actually it doesn't work for any role
13:35:14 <sdague> oh....
13:36:06 <alex_xu> how about this: nova-policy policy checks --user-id "..uuid.." --porject-id "..uuid.." --role "admin" "xyz"...
13:36:37 <alex_xu> everything input by user
13:37:05 <sdague> alex_xu: that seems reasonable starting point
13:37:23 <sdague> I haven't seen claudio around in a bit, is anyone able to respin that
13:37:53 <alex_xu> i'm ok with that
13:39:07 <sdague> ok, we still need someone to own this, otherwise it is unlikely to land
13:39:22 <alex_xu> yea, I will own this
13:40:17 <sdague> alex_xu: thank you
13:40:36 <alex_xu> #action alex_xu help on the respin the policy check cmd patches
13:40:38 <alex_xu> sdague: np
13:40:50 <alex_xu> I think that is all we have before release?
13:42:03 <alex_xu> ok, i think that is all
13:42:07 <alex_xu> #topic open
13:42:22 <alex_xu> anyone want to bring up something?
13:43:05 <alex_xu> cdent: sdague what is plan for placement API? merge them all, or just try our best?
13:43:09 <sdague> was was the last microversion we were going to land, after get me a network?
13:43:23 <alex_xu> sdague: ah, i forget that one
13:43:28 <edleafe> sdague: 2.38
13:43:33 <cdent> alex_xu: the goal is to at least get inventories written
13:43:35 <edleafe> sdague: working on pushing that now
13:43:38 <sdague> edleafe: ok
13:43:52 <sdague> cdent: what is the patch where that happens?
13:43:52 <cdent> but most of the rest of the code is close, just waiting on some stuff to merge to make real progress
13:44:03 <sdague> so we can keep an eye on getting up to that point
13:44:12 <cdent> sdague: https://review.openstack.org/#/c/329152/
13:44:12 <alex_xu> edleafe: do you have link?
13:44:32 <alex_xu> cdent: cool
13:44:37 <cdent> that was in the stack you've already reviewed, but we've started to unstack so as to enable some parallelism
13:44:49 <cdent> but given the delay in the gate, the rebases are on hold
13:44:53 <edleafe> #link https://review.openstack.org/#/c/315964/
13:44:55 <edleafe> alex_xu: ^^
13:44:59 <alex_xu> edleafe: thanks
13:45:09 <cdent> sdague: that patch probably has the same issues with empty response bodies as the resource provider urls one
13:45:39 <cdent> related to the placement api I wanted to point at this https://gist.github.com/cdent/de50cb05a7ab8219cd4f5b4ab3c181dd
13:46:05 <cdent> that's a POC of microversion decorators in the placement api, based off the nova code, but modified for the differences
13:46:23 <sdague> ok, keeping in them in a stack actually makes it a little easier to know when we hit the finish line
13:46:23 <cdent> it's incomplete, and there is no where to put it yet (as there are no versions) but I wanted to make sure people are aware that it is being thought about
13:46:44 <cdent> sdague: yeah, that's what I think, but I keep getting "why is this based on X" comments
13:47:03 <sdague> cdent: hmm, ok, maybe we should just educate folks on that
13:47:31 <alex_xu> cdent: cool for decorator
13:47:38 <cdent> sdague: they are from people who I'm pretty sure already know that (jay, dan, etc)
13:47:47 <sdague> sigh, ok
13:48:16 <cdent> I think they (understandbly) are tying to optimize for merging, not waiting
13:48:46 <cdent> in any case, once the three currently merging are in, it will be a lot easier to make sense of
13:48:53 <sdague> ok, from my math this is only 4 patches outstanding right?
13:49:53 <cdent> sdague: I need to review the actual goals more closely but I think there are several "we'd really like to get this too" but I'm not sure how those relate to the decisions made at mid-cycle and elsewhere
13:50:04 <cdent> I admit that it is hard for me to understand some of the constraints
13:50:11 <cdent> so I just keep moving as much forward as I cn
13:50:12 <cdent> can
13:50:22 <sdague> ok, lets take this back over to nova channel
13:50:29 <sdague> so we can get everyone on the same page
13:51:01 <alex_xu> ok, so anything more? or we probably need to close the meeting
13:51:19 <sdague> yeh, probably close the meeting
13:51:25 * cdent nods
13:51:29 <alex_xu> cool, 9 mins left, we have short meeting this week. :)
13:51:30 <sdague> I am unlikely to be here next week, because of OpenStack East
13:51:43 <mriedem> i'm on vacation next week too
13:51:52 <mriedem> cranking on the novaclient changes today
13:51:59 <alex_xu> woo, catch all the question this week.
13:52:07 <alex_xu> ok, thanks all!
13:52:10 <alex_xu> #endmeeting