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