13:00:07 #startmeeting nova api 13:00:08 Meeting started Wed Jan 4 13:00:07 2017 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:11 The meeting name has been set to 'nova_api' 13:00:17 who is here today? 13:00:25 o/ 13:00:33 o/ 13:00:59 let us wait one more minute 13:02:25 i'm not sure all the people back from holiday yet 13:02:31 so.... 13:02:36 o/ 13:02:45 #topic open 13:03:03 #link https://review.openstack.org/#/c/393205/ 13:03:12 the servers filter spec merged \o/ 13:03:30 #link https://review.openstack.org/#/q/status:open++branch:master+topic:bp/consistent-query-parameters-validation 13:03:40 the base part is close i guess 13:03:51 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/add-whitelist-for-server-list-filter-sort-parameters 13:03:52 I found some typo in the spec when I coding though 13:04:05 Kevin_Zheng is working on the servers list query parameters 13:04:11 Kevin_Zheng: which one? 13:04:27 Kevin_Zheng: oops, you mean the spec, we can fix it quickly 13:04:29 https://review.openstack.org/#/c/415115/ 13:04:35 yeah 13:05:51 yeah, that looks like good fixes to me 13:06:09 all_tenants missing its s was the nasty one I guess 13:06:18 haha yes 13:06:36 For filters, return 400 when joined-table and internal attributes specified, I didn't find a good implementation 13:07:35 Is it ok we only return 400 for sort with joined-table and internal attributes? For filters, we just ignore all the extra filters, that also matches the current filters behaviour 13:08:12 Probably I just want to remove the 'filters' from this line https://review.openstack.org/#/c/393205/21/specs/ocata/approved/add-whitelist-for-server-list-filter-sort-parameters.rst@45 13:09:09 hmm, maybe 13:09:29 its a shame to go from 500 error to silent failure 13:11:42 actually we ignore extra filters also 13:11:49 only not ignore few of them 13:12:26 But we can have a try the implement it, I have a idea, then we take a look at whether we want to put that in the code 13:13:57 it will pretty similar to sort implementation https://review.openstack.org/#/c/415142/11/nova/api/validation/parameter_types.py 13:14:37 yeah, seems worth a try 13:14:58 I mean we might decide its better not to bother, but I would like to try 13:15:10 ok, cool 13:15:25 longer term, we add a microversion and they are all 400 I guess 13:15:30 Kevin_Zheng: later I will talk to you the idea with chinese :) 13:15:40 johnthetubaguy: yea 13:15:42 yeah 13:16:02 I guess if we can get closer to that, cool, if not, then we know how to fix it later 13:16:27 ok 13:17:15 so...we only this one priority task. and we are cool now 13:17:27 anything more people want to talk about? 13:18:00 #link https://etherpad.openstack.org/p/ocata-nova-priorities-tracking 13:18:31 o/ 13:18:40 ^ we have few non-priority api changes, I also put them in the etherpad, people can track it 13:18:59 awesome, thats my usual question answered already 13:19:26 sdague: anything more in your mind, we are close to the end of meeting :) 13:19:50 nope, I'm fine, just saying I was around, I can start reviewing code before too long 13:20:08 #link https://review.openstack.org/386555 13:20:21 johnthetubaguy: sdague in the priority task, we also mention ^ that 13:20:40 but except review, i guess there isn't any more we can do for it, right? 13:21:13 yeah, if we could all be +1 on that before the PTG, so we can talk about an implementation plan at the PTG, that would be awesome 13:21:32 or ideally have a nova spec to agree before the PTG I guess 13:22:45 ok, try to review it more 13:23:01 cdent has some interesting questions on that one about instance capabilities, not sure I understand his concern yet 13:23:21 * cdent refreshes his memory 13:23:34 ah, that 13:23:54 my main concern is that capabilities should be on types, not instances 13:23:59 I guess its GET /volume/{volume_id}/capabilities vs adding caps into GET /volume/{volume_id} ? 13:24:07 cdent: its on both right now 13:24:15 right, and I think that's wrong 13:24:17 basically because the type is not a type, its more a template 13:24:48 if an instance of thing has special capabilities, those things should be represented _within_ the resource's representation 13:24:50 flavor + image gives you something thats a combination of the two 13:24:50 as they are specific to it 13:24:59 a capability ought to be a generic thing 13:25:43 so GET /volume/{volume_id}/capabilities vs adding caps into GET /volume/{volume_id} ? 13:26:04 I also worry that we are thinking about capabilities with too much of an eye to existing situations in nova and cinder, rather than a more general thing. Obviously those things need to meet somewhere in the middle (not be just general) but I think we can consider the general case a bit more. 13:26:14 its not data we return today, basically something missing in the representation 13:26:20 yeah 13:26:59 /capabilities/volume is a fairly static thing (but deployment specific) 13:27:11 whereas /volume/{volument_id} _has_ capabilities 13:27:20 that are dependent on "stuff" 13:28:29 so to be specific, the example is "can I do a volume backup?" 13:28:50 it feels like from a user perspective though the question the user is going to ask is "can I do X to this thing in front of me" 13:28:53 some clouds don't do that, some volume types don't do that, and some volumes land somewhere thats not possible 13:28:54 for any volumen, we answer that question under /capabilities 13:29:00 for an existing volume, we ask the volume 13:29:19 (goodness my typing is poor) 13:29:49 well, I think can any volume in this cloud do action X? can any volume of this type do action X? can my volume uuid-5 do action X? 13:30:01 all seems the same question to me 13:30:46 as sdague said, really just thinking about the question the API user is trying to answer (it includes policy and ability of the system) 13:30:59 * cdent nods 13:31:20 most of the discussion seemed to be around how to represent the actions 13:31:25 If the question is "can X do this thing" why should I ask something else, other than X, that question? 13:31:39 and, at least on the nova side, potentially the hypervisor type & version the instance landed on, so cant' just be flavor 13:31:47 because you want to know what type to pick if you want to do X? 13:32:09 I want to do a snapshot, I can't use the ironic only cloud, and I can't use that ironic flavor over there 13:32:10 I think you mean "Y" because "X" is a thing I already have 13:32:21 that's the two different questions: 13:32:29 when I use this cloud can I do activity A 13:32:36 when I use this entity can I do activity A 13:32:58 on the latter question, why shouldn't we ask the entity? 13:33:01 for me thats a scope, there are three scopes 13:33:12 we are proposing you do ask the entity, I believe 13:33:21 well, ish 13:33:25 the spec proposes a new url 13:33:35 and my concern is adding yet more urls 13:33:42 so there is an implementation detail 13:33:46 instead of having more useful representations 13:34:02 to find the capabilitiy, we need to make an RPC call to the compute node, so including it by default is really expense 13:34:10 I suspect we missed that bit 13:34:40 _that_ is an implementation detail of Nova, thus my point above about meeting in the middle between general correctness, and needing to deal with nova/cinder implementation concerns 13:35:54 obviously we have to be concerned about the cost of these things to nova etc, but we can also be aware of how they can inform different/better implementations in the future 13:36:22 GET /volume/{volume_id}?include_capabilties=True 13:36:27 would that be better? 13:36:46 If the reason for have /foo/{id}/capabilities is a performance optimization, we should say so. 13:37:04 cdent: totally agree, thats missing in the spec right now, just adding that comment 13:37:30 given a choice between a query param and a sub resource I'd tend to go for subresource simply because it looks prettier :) 13:37:41 frankly I forgot about that (again) till 10 mins ago 13:37:49 cdent: yeah, I am with you 13:38:36 anyways, thanks cdent, that makes good sense to me now 13:38:39 When I come back around to that review, I'll try to a) make my concerns more clear b) make it clear my concerns are not blocking, more for highlighting issues etc 13:38:40 I guess we keep pushing on that spec 13:39:13 +1 13:40:01 so...it turn to me say... anything more? 13:40:18 I am all good, thanks for pushing on all that over the holidays 13:40:24 getting there now 13:40:34 \o/ 13:40:47 thanks Kevin_Zheng will take care those patches 13:41:03 NP 13:41:08 thanks for the review 13:41:17 so... we can close the meeting now 13:41:23 thanks all 13:41:28 #endmeeting