13:00:01 <alex_xu> #startmeeting nova api
13:00:02 <openstack> Meeting started Wed Dec  7 13:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:05 <openstack> The meeting name has been set to 'nova_api'
13:00:09 <alex_xu> who is here today?
13:00:14 <Kevin_Zheng> o/
13:00:14 <gcb> o/
13:00:20 <jichen> o/
13:00:30 <qwebirc70038> hi
13:00:44 <qwebirc70038> o/
13:00:51 <gmann_> o/
13:01:03 <gcb> hi jichen
13:01:14 <jichen> gcb :)
13:01:14 <alex_xu> let us wait one more minute
13:02:44 <alex_xu> ok, looks like johnthetubaguy and sdague aren't around here today
13:02:53 <gmann_> oh
13:03:18 <alex_xu> I saw sdague two mins ago, but I didn't see johnthetubaguy today
13:03:37 <alex_xu> so first, let me quick update the status
13:04:07 <alex_xu> we will have priority task related specs merge in ocata.
13:04:18 <alex_xu> one spec is still under discussion
13:04:42 <alex_xu> #link https://review.openstack.org/393205
13:04:43 <gmann_> filter one
13:04:48 <alex_xu> gmann_: yea
13:05:16 <gmann_> i will also check tomorrow.
13:05:22 <Kevin_Zheng> hard one...
13:05:42 <gmann_> Kevin_Zheng: yea but nice work
13:05:43 <alex_xu> looks like sdague have conern about the policy to enable the ignored filter. And I'm still feel we should use microversion for adding filter which mapping to the API field
13:07:03 <sdague> o/
13:07:34 <alex_xu> except the priority task, we have 4 non-priotiy specs merged, and most of them are patch ready
13:07:36 <gmann_> version bump will be helpful if user using those filter wrongly and once we enable it start returning filtered servers
13:08:09 <alex_xu> #link https://etherpad.openstack.org/p/ocata-nova-priorities-tracking
13:08:26 <alex_xu> ^ I put all the patches which are ready in the etherpad
13:09:07 <Kevin_Zheng> cool
13:09:09 <alex_xu> #link https://review.openstack.org/377528
13:09:18 <alex_xu> #link https://review.openstack.org/386771
13:09:28 <alex_xu> ^ those two are very close I think
13:10:10 <alex_xu> so...that is update from me. I think the left time we can focus on the filter one :)
13:12:29 * gmann_ need to look at latest version (lot of discussion there).
13:13:04 <sdague> https://review.openstack.org/#/c/377528/ being the filter one?
13:13:23 <alex_xu> sdague: sorry, I mean https://review.openstack.org/#/c/393205/
13:13:38 <sdague> ah, yeh
13:13:42 <sdague> that's the one I meant as well
13:14:01 <sdague> so, pretty much, I just wanted to prune down the differences between the lists
13:14:08 <sdague> whenever we can
13:14:23 <sdague> host / node seems to be the only real issue there
13:14:42 <alex_xu> host is the realy host name, it isn't the hash
13:15:02 <sdague> what is the name of the field that gets exposed that's the hash?
13:15:13 <alex_xu> hostid
13:15:31 <alex_xu> s/hostid/hostId/
13:15:43 <sdague> ok
13:15:49 <alex_xu> hostId is calculated at api layer
13:15:52 <alex_xu> based on the host
13:15:54 <sdague> right
13:16:22 <sdague> so... not that we should fix this now, but in an ideal world I feel like we'd only have one field we expose to the user: host
13:16:29 <sdague> and if you are a normal user, it's the hash
13:16:39 <sdague> and if you are a priv user, it's the real hostname
13:16:56 <alex_xu> sdague: yea, that sounds better
13:17:40 <sdague> and I want to get rid of the policy point for this
13:17:57 <sdague> alex_xu: I think you were good with making the lists as close as possible
13:18:07 <alex_xu> sdague: thanks
13:18:08 <sdague> how do you feel about removing the policy control
13:18:12 <sdague> ?
13:18:49 <alex_xu> actually the policy control is pointed by johnthetubaguy, the point is we give a chance to the user if they really depend on some parameters we just removed it
13:19:40 <alex_xu> sdague: actually I'm on the side for afraid break user :)
13:20:23 <alex_xu> but yes, that totally undiscoverable.
13:20:40 <gmann_> policy control means on ignored ones ?
13:20:41 <alex_xu> really hope we have capabilities discovery right now
13:21:00 <alex_xu> gmann_: at line 87 of https://review.openstack.org/#/c/393205/10/specs/ocata/approved/add-whitelist-for-server-list-filter-sort-parameters.rst
13:21:40 <alex_xu> gmann_: it means enable or ignore the unsafed/bad parameters.
13:22:02 <gmann_> i see
13:23:23 <alex_xu> sorry, I just drop the network
13:24:02 <gmann_> but if those did not gave filtered list in current situation (jointed table etc)might be ok  but yea for other they can be break
13:24:46 <alex_xu> sdague: I didn't have strong point now. give it is undiscoverable. And if we decide to remove all the bad stuff. then yes, remove that policy control
13:25:24 <alex_xu> gmann_: yea, so just ignore them can avoid break the user's code directly
13:25:38 <gmann_> yea
13:25:44 <alex_xu> gmann_: just the result didn't return expected
13:26:22 <gmann_> but that should be ok, people knows unindexed/bad one can be unsupported any time with bug fix etc
13:27:10 <alex_xu> gmann_: emm...yea
13:28:00 <alex_xu> gmann_: and it is almost only for admin user
13:28:14 <alex_xu> for filters
13:28:51 <alex_xu> I keep the full list for non-admin user https://github.com/openstack/nova/blob/f8a81807e016c17e6c45d318d5c92ba0cc758b01/nova/api/openstack/compute/servers.py#L1103
13:29:07 <gmann_> yea nice point, that also makes less usage
13:29:47 <gmann_> yes non-admin one were fine
13:29:53 <sdague> so, we're not going to break users exactly, they'll just get more results back for undocumented behavior
13:30:16 <gmann_> yea
13:30:44 <alex_xu> I'm searching the meeting log
13:30:46 <alex_xu> <johnthetubaguy> we got direct feedback on this at the summit, from operators saying don't break my searching
13:31:07 <alex_xu> ^ that is the point John worry about
13:31:38 <sdague> ok... well, we could decide to add that bit late, right?
13:31:55 <alex_xu> emm...yes
13:32:13 <sdague> so move forward with that as a thing to think about once johnthetubaguy gets back
13:32:20 <sdague> but the rest of it could get put together
13:33:39 <alex_xu> sdague: sorry, I didn't get you for last sentence
13:34:13 <sdague> alex_xu: I'm trying to make sure we don't stall out on that policy point
13:34:46 <alex_xu> sdague: yea, that is good idea
13:34:53 <sdague> and that we can move the code forward and think about how to resolve that last bit once we have everyone around
13:35:15 <alex_xu> +1 for the plan
13:35:29 <gmann_> yea
13:36:00 <alex_xu> sdague: and for add mapping sort, like add sort key display_name which is mapping to db name column. I feel this needs a microversion
13:36:01 <sdague> is there any code up for any of the rest of it yet?
13:36:28 <sdague> alex_xu: what needs a microversion?
13:36:35 <alex_xu> sdague: the base patch is ready https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/consistent-query-parameters-validation
13:36:57 <alex_xu> sdague: the line 137 - 141 of https://review.openstack.org/#/c/393205/10/specs/ocata/approved/add-whitelist-for-server-list-filter-sort-parameters.rst
13:37:52 <alex_xu> currently the sort_key are mapping to the DB column name directly. that proposal to add a set of new sort_key which mapping the name of API field
13:38:24 <alex_xu> I hesitate that should be added by microversion, and maybe another spec
13:41:31 <alex_xu> emm....
13:41:44 <alex_xu> sdague: are you still around?
13:42:37 <alex_xu> or I have network problem...
13:42:59 <gmann_> or if we are not sure then how about  we mention in this spec that decision can be taken at time when those will be proposed ?
13:44:30 <alex_xu> gmann_: sorry I didn't get you also
13:44:45 <gmann_> oh, i was saying about microversion bump decision
13:45:38 <gmann_> as that can be with new spec and move with current proposal of filter things  ?
13:45:58 <gmann_> but not sure sdague  point on that.
13:46:23 <alex_xu> gmann_: yea, that sounds good also. I think that isn't key thing we want to achive in the spec
13:46:34 <gmann_> yea
13:47:50 <alex_xu> ok, so the next thing is we can begin to work on the patch
13:48:01 <gmann_> sdague: seems not here :). if nothing more, may be we can move to next topic
13:48:08 <gmann_> alex_xu: yes
13:48:14 <alex_xu> yea
13:48:22 <alex_xu> #topic open
13:48:27 <alex_xu> anthing for open?
13:48:35 <alex_xu> s/anthing/anything/
13:49:07 <gmann_> alex_xu: as we discussed on IRC about this - https://review.openstack.org/#/c/402372/
13:49:42 <gmann_> but sdague  johnthetubaguy  not available now, may be  we can discuss that later
13:49:53 <alex_xu> gmann_: yea, :)
13:49:56 <Kevin_Zheng> yea
13:50:23 <gmann_> alex_xu: because i am very afraid on that as it change create server to 400 which is very common API
13:50:28 <gmann_> ok
13:50:37 <alex_xu> gmann_: yea, I see your point
13:51:01 <alex_xu> gmann_: sounds like we face those hard problem many times :)
13:51:13 <gmann_> yea :)
13:51:32 <alex_xu> I totally hate to answer similar question :)
13:51:50 <sdague> alex_xu: sorry, I got pulled away briefly
13:51:51 <gmann_> heh
13:52:20 <alex_xu> sdague: no worries
13:52:24 <gmann_> sdague:  we need your feedback on this - https://review.openstack.org/#/c/402372/
13:52:26 <sdague> so, lets start with the keys that we currently filter by, and I agree we should probably add a new set of keys as a microversion
13:52:36 <gmann_> oh. sorry
13:52:38 <sdague> I would like to bunch them up though so we add a bunch at once
13:52:39 <alex_xu> sdague: cool
13:52:50 <sdague> and not do them one at a time
13:53:13 <alex_xu> cool, the patch can be started now
13:55:00 <alex_xu> ok, I think that is all
13:55:08 <alex_xu> sdague: looking your feedback on https://review.openstack.org/402372
13:55:18 <alex_xu> gmann_: we can just wait Sean feedback on the patch
13:55:29 <sdague> ok, I'll look after the meeting
13:55:35 <alex_xu> sdague: thanks
13:55:39 <alex_xu> anytihng more want to bring up?
13:55:46 <gmann_> sdague: thanks
13:56:13 <alex_xu> looks like no
13:56:18 <alex_xu> so, thanks all!
13:56:26 <alex_xu> #endmeeting