13:00:07 <alex_xu> #startmeeting nova api
13:00:08 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:11 <openstack> The meeting name has been set to 'nova_api'
13:00:17 <alex_xu> who is here today?
13:00:25 <Kevin_Zheng> o/
13:00:33 <cdent> o/
13:00:59 <alex_xu> let us wait one more minute
13:02:25 <alex_xu> i'm not sure all the people back from holiday yet
13:02:31 <alex_xu> so....
13:02:36 <johnthetubaguy> o/
13:02:45 <alex_xu> #topic open
13:03:03 <alex_xu> #link https://review.openstack.org/#/c/393205/
13:03:12 <alex_xu> the servers filter spec merged \o/
13:03:30 <alex_xu> #link https://review.openstack.org/#/q/status:open++branch:master+topic:bp/consistent-query-parameters-validation
13:03:40 <alex_xu> the base part is close i guess
13:03:51 <alex_xu> #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 <Kevin_Zheng> I found some typo in the spec when I coding though
13:04:05 <alex_xu> Kevin_Zheng is working on the servers list query parameters
13:04:11 <alex_xu> Kevin_Zheng: which one?
13:04:27 <alex_xu> Kevin_Zheng: oops, you mean the spec, we can fix it quickly
13:04:29 <Kevin_Zheng> https://review.openstack.org/#/c/415115/
13:04:35 <Kevin_Zheng> yeah
13:05:51 <johnthetubaguy> yeah, that looks like good fixes to me
13:06:09 <johnthetubaguy> all_tenants missing its s was the nasty one I guess
13:06:18 <Kevin_Zheng> haha yes
13:06:36 <alex_xu> For filters, return 400 when joined-table and internal attributes specified, I didn't find a good implementation
13:07:35 <alex_xu> 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 <alex_xu> 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 <johnthetubaguy> hmm, maybe
13:09:29 <johnthetubaguy> its a shame to go from 500 error to silent failure
13:11:42 <alex_xu> actually we ignore extra filters also
13:11:49 <alex_xu> only not ignore few of them
13:12:26 <alex_xu> 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 <alex_xu> it will pretty similar to sort implementation https://review.openstack.org/#/c/415142/11/nova/api/validation/parameter_types.py
13:14:37 <johnthetubaguy> yeah, seems worth a try
13:14:58 <johnthetubaguy> I mean we might decide its better not to bother, but I would like to try
13:15:10 <alex_xu> ok, cool
13:15:25 <johnthetubaguy> longer term, we add a microversion and they are all 400 I guess
13:15:30 <alex_xu> Kevin_Zheng: later I will talk to you the idea with chinese :)
13:15:40 <alex_xu> johnthetubaguy: yea
13:15:42 <Kevin_Zheng> yeah
13:16:02 <johnthetubaguy> I guess if we can get closer to that, cool, if not, then we know how to fix it later
13:16:27 <alex_xu> ok
13:17:15 <alex_xu> so...we only this one priority task. and we are cool now
13:17:27 <alex_xu> anything more people want to talk about?
13:18:00 <alex_xu> #link https://etherpad.openstack.org/p/ocata-nova-priorities-tracking
13:18:31 <sdague> o/
13:18:40 <alex_xu> ^ we have few non-priority api changes, I also put them in the etherpad, people can track it
13:18:59 <johnthetubaguy> awesome, thats my usual question answered already
13:19:26 <alex_xu> sdague: anything more in your mind, we are close to the end of meeting :)
13:19:50 <sdague> nope, I'm fine, just saying I was around, I can start reviewing code before too long
13:20:08 <alex_xu> #link  https://review.openstack.org/386555
13:20:21 <alex_xu> johnthetubaguy: sdague in the priority task, we also mention ^ that
13:20:40 <alex_xu> but except review, i guess there isn't any more we can do for it, right?
13:21:13 <johnthetubaguy> 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 <johnthetubaguy> or ideally have a nova spec to agree before the PTG I guess
13:22:45 <alex_xu> ok, try to review it more
13:23:01 <johnthetubaguy> 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 <cdent> ah, that
13:23:54 <cdent> my main concern is that capabilities should be on types, not instances
13:23:59 <johnthetubaguy> I guess its  GET /volume/{volume_id}/capabilities vs adding caps into  GET /volume/{volume_id} ?
13:24:07 <johnthetubaguy> cdent: its on both right now
13:24:15 <cdent> right, and I think that's wrong
13:24:17 <johnthetubaguy> basically because the type is not a type, its more a template
13:24:48 <cdent> if an instance of thing has special capabilities, those things should be represented _within_ the resource's representation
13:24:50 <johnthetubaguy> flavor + image gives you something thats a combination of the two
13:24:50 <cdent> as they are specific to it
13:24:59 <cdent> a capability ought to be a generic thing
13:25:43 <johnthetubaguy> so GET /volume/{volume_id}/capabilities vs adding caps into  GET /volume/{volume_id} ?
13:26:04 <cdent> 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 <johnthetubaguy> its not data we return today, basically something missing in the representation
13:26:20 <cdent> yeah
13:26:59 <cdent> /capabilities/volume is a fairly static thing (but deployment specific)
13:27:11 <cdent> whereas /volume/{volument_id} _has_ capabilities
13:27:20 <cdent> that are dependent on "stuff"
13:28:29 <johnthetubaguy> so to be specific, the example is "can I do a volume backup?"
13:28:50 <sdague> 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 <johnthetubaguy> some clouds don't do that, some volume types don't do that, and some volumes land somewhere thats not possible
13:28:54 <cdent> for any volumen, we answer that question under /capabilities
13:29:00 <cdent> for an existing volume, we ask the volume
13:29:19 <cdent> (goodness my typing is poor)
13:29:49 <johnthetubaguy> 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 <johnthetubaguy> all seems the same question to me
13:30:46 <johnthetubaguy> 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 <johnthetubaguy> most of the discussion seemed to be around how to represent the actions
13:31:25 <cdent> If the question is "can X do this thing" why should I ask something else, other than X, that question?
13:31:39 <sdague> and, at least on the nova side, potentially the hypervisor type & version the instance landed on, so cant' just be flavor
13:31:47 <johnthetubaguy> because you want to know what type to pick if you want to do X?
13:32:09 <johnthetubaguy> 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 <cdent> I think you mean "Y" because "X" is a thing I already have
13:32:21 <cdent> that's the two different questions:
13:32:29 <cdent> when I use this cloud can I do activity A
13:32:36 <cdent> when I use this entity can I do activity A
13:32:58 <cdent> on the latter question, why shouldn't we ask the entity?
13:33:01 <johnthetubaguy> for me thats a scope, there are three scopes
13:33:12 <johnthetubaguy> we are proposing you do ask the entity, I believe
13:33:21 <johnthetubaguy> well, ish
13:33:25 <cdent> the spec proposes a new url
13:33:35 <cdent> and my concern is adding yet more urls
13:33:42 <johnthetubaguy> so there is an implementation detail
13:33:46 <cdent> instead of having more useful representations
13:34:02 <johnthetubaguy> 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 <johnthetubaguy> I suspect we missed that bit
13:34:40 <cdent> _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 <cdent> 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 <johnthetubaguy> GET /volume/{volume_id}?include_capabilties=True
13:36:27 <johnthetubaguy> would that be better?
13:36:46 <cdent> If the reason for have /foo/{id}/capabilities is a performance optimization, we should say so.
13:37:04 <johnthetubaguy> cdent: totally agree, thats missing in the spec right now, just adding that comment
13:37:30 <cdent> 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 <johnthetubaguy> frankly I forgot about that (again) till 10 mins ago
13:37:49 <johnthetubaguy> cdent: yeah, I am with you
13:38:36 <johnthetubaguy> anyways, thanks cdent, that makes good sense to me now
13:38:39 <cdent> 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 <johnthetubaguy> I guess we keep pushing on that spec
13:39:13 <cdent> +1
13:40:01 <alex_xu> so...it turn to me say... anything more?
13:40:18 <johnthetubaguy> I am all good, thanks for pushing on all that over the holidays
13:40:24 <johnthetubaguy> getting there now
13:40:34 <alex_xu> \o/
13:40:47 <alex_xu> thanks Kevin_Zheng will take care those patches
13:41:03 <Kevin_Zheng> NP
13:41:08 <Kevin_Zheng> thanks for the review
13:41:17 <alex_xu> so... we can close the meeting now
13:41:23 <alex_xu> thanks all
13:41:28 <alex_xu> #endmeeting