06:00:01 <gmann> #startmeeting nova api
06:00:02 <openstack> Meeting started Wed Jul 11 06:00:01 2018 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:00:05 <openstack> The meeting name has been set to 'nova_api'
06:00:11 <gmann> PING List: gmann, alex_xu
06:00:14 <gmann> who all here today
06:00:15 <alex_xu> o/
06:00:19 <gmann> alex_xu: hi
06:00:29 <alex_xu> gmann: good afternoon
06:00:38 <gmann> good afternoon
06:01:00 <jichen> o/
06:01:03 <Kevin_Zheng> o/
06:01:41 <gmann> jichen: Kevin_Zheng : hi
06:01:46 <gmann> let's start
06:01:59 <gmann> #link https://wiki.openstack.org/wiki/Meetings/NovaAPI#Agenda_for_next_Office_hours
06:02:11 <gmann> ^^ generic agenda for this office hour
06:02:15 <yikun> o/
06:02:22 <gmann> yikun: hi
06:02:35 <gmann> #topic Priorities
06:02:45 <gmann> #link https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
06:02:57 <gmann> we will go through the API section in above etherpad
06:03:06 <jichen> ok
06:03:17 <gmann> line 57
06:03:33 <gmann> 1. Servers Ips non-unique network names
06:03:54 <gmann> spec update is merged last week. #link https://review.openstack.org/#/c/558125/
06:05:27 <gmann> Maciej Kucia started code also but month  back
06:06:07 <jichen_> Is there code patch ? I only saw a doc patch
06:06:17 <gmann> i do not irc nick and changes should be straight forwards. if no updated since week, may be i can update the code for this BP
06:06:38 <gmann> yea, that patch only. in same patch code needs to be updated.
06:06:57 <gmann> i will check with Maciej  about progress.
06:07:04 <gmann> 2.Abort live migration in queued state:
06:07:04 <jichen_> ok, got it
06:07:41 <gmann> this is from Kevin_Zheng and  i think good to review from us. i have added this in my today list.
06:08:23 <Kevin_Zheng> I got a question about this one
06:08:28 <gmann> Kevin_Zheng: anything you want to discuss on this then review
06:08:28 <Kevin_Zheng> API related
06:08:37 <gmann> yeah go head
06:08:49 <Kevin_Zheng> in the patch, I have a rpc version check
06:09:18 <Kevin_Zheng> like if the compute can do 5.1 then it can abort migration in queued status
06:09:23 <Kevin_Zheng> if cannot do 5.1
06:09:33 <Kevin_Zheng> then I trough an exception
06:09:50 <Kevin_Zheng> my question is, should I mention that compute is not new enoguh?
06:09:53 <Kevin_Zheng> enough
06:10:13 <gmann> you mean this -
06:10:15 <gmann> #link https://review.openstack.org/#/c/568542
06:10:18 <Kevin_Zheng> will that be too much admin details for normal user?
06:10:57 <Kevin_Zheng> yeah
06:11:10 <Kevin_Zheng> if it is like what I did in the current patch
06:11:57 <Kevin_Zheng> it seems a little wierd, as an user I requested 2.64 and then nova replied to me that migration is not in correct status
06:11:58 <alex_xu> I think we have some example in the before
06:12:23 <Kevin_Zheng> seems not correct with the mircorversion
06:12:34 <gmann> yeah i am searching for that
06:12:50 <Kevin_Zheng> Yeah, we have some, yikun is also working on one with this kind of server version check
06:13:18 <Kevin_Zheng> just wondering if it is good to let normal user know that some of the node is not new enough
06:13:39 <yikun> ^ https://review.openstack.org/#/c/567534/30/nova/api/openstack/compute/server_groups.py@190
06:13:40 <gmann> this one -
06:13:42 <gmann> #link https://github.com/openstack/nova/blob/d3fa585f5e2d11a91ee62744a0cf0c78921a47e4/nova/compute/api.py#L1033
06:14:24 <gmann> you can add new exception like this  - #link https://github.com/openstack/nova/blob/c8b93fa2493dce82ef4c0b1e7a503ba9b81c2e86/nova/exception.py#L2294
06:14:55 <Kevin_Zheng> hmm that seems better
06:15:21 <Kevin_Zheng> Yikun, maybe you should do something similar?
06:15:23 <yikun> yeah, so we should NOT expose something like "all compute services needs upgrade to Rocky"
06:15:27 <gmann> Kevin_Zheng:  we will tell node is old we will just say this feature not supported so that user will contact admin for details
06:15:28 <Kevin_Zheng> yeah
06:15:34 <alex_xu> also this one #link https://github.com/openstack/nova/blob/stable/ocata/nova/compute/rpcapi.py#L1114
06:15:53 <Kevin_Zheng> maybe the version thing should be appare in the log?
06:15:57 <gmann> yeah crash dump one alaos
06:16:07 <gmann> Kevin_Zheng: i think no.
06:17:07 <Kevin_Zheng> why not, seems better for operators
06:17:52 <jichen> yes, logs are only viewable to operators...
06:17:55 <alex_xu> why we didn't check service version instead of rpc version?
06:18:09 <Kevin_Zheng> they are different cases
06:18:17 <gmann> for which case
06:18:20 <Kevin_Zheng> yikun's case we check service version
06:18:27 <Kevin_Zheng> my case check for rpc version
06:18:40 <Kevin_Zheng> for log, I mean both version
06:18:44 <Kevin_Zheng> both case
06:19:35 <gmann> but operator knows features support from reno and microversions info.
06:19:47 <alex_xu> Kevin_Zheng: I mean your case can be done by the service version check also?
06:21:39 <Kevin_Zheng> yeah, but this way is similar, I also did some negotiation in rpc
06:21:43 <gmann> alex_xu: you mean in compute.api.py only like thrust certificate
06:22:02 <alex_xu> gmann: yea
06:22:34 <gmann> ok, that seems better for me too
06:22:41 <alex_xu> we can stop the API early, and it is more clear in the code
06:22:45 <Kevin_Zheng> I don't think so
06:23:05 <Kevin_Zheng> it is not the same with the certificate one
06:23:24 <Kevin_Zheng> my patch is depend on the migration status
06:23:31 <Kevin_Zheng> and it changes
06:23:53 <Kevin_Zheng> maybe when we check at api, it is not running
06:24:13 <Kevin_Zheng> but if we check again at rpc, which is the last step before we go to compute
06:24:22 <Kevin_Zheng> it changed to running
06:24:34 <Kevin_Zheng> and the API call will be success
06:25:02 <Kevin_Zheng> it is not like certificate that if it is not supported, it will be always not supported
06:25:43 <alex_xu> that is very short window...
06:26:27 <alex_xu> I just feel the rpc version check is very low level. we should have consistent check by the service version in the future.
06:26:55 <Kevin_Zheng> also
06:27:06 <Kevin_Zheng> Dan have a comment about this in
06:27:34 <Kevin_Zheng> https://review.openstack.org/#/c/568542/15/nova/compute/rpcapi.py
06:28:19 <alex_xu> ah, sounds like similar question, I will read it
06:28:53 <alex_xu> I think we can move on, continue this discussion on the patch
06:29:01 <Kevin_Zheng> NP
06:29:28 <gmann> yeah, let's have discussion on patch and what dansmith is saying.
06:29:33 <gmann> let's move next
06:29:48 <gmann> 3. Complex anti-affinity policies:
06:29:58 <gmann> #link https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)
06:30:18 <gmann> this if yikun is working  and seems good amount of review
06:31:06 <gmann> during discussion on falt vs dict representation of policy, REST API response is changing here than what was approved ins epc
06:31:11 <gmann> which seem better way
06:31:35 <gmann> #link https://review.openstack.org/#/c/567534/
06:31:52 <gmann> my concern is to make the same for reqeust also
06:32:23 <yikun> yeah, and some question we have:
06:32:24 <gmann> yikun: any objection on that ^^ and alex_xu what you say about new format of 'policy' in request and response
06:32:35 <yikun> 1. should we change api response and req to flat policy?
06:32:38 <yikun> https://review.openstack.org/#/c/546925/18/specs/rocky/approved/complex-anti-affinity-policies.rst@130
06:33:30 <yikun> 2. if we change these to flat, should we change to policy_*
06:33:31 <gmann> i am fine for changing in both.
06:34:03 <gmann> #link https://review.openstack.org/#/c/563401/28/nova/notifications/objects/server_group.py@41
06:34:16 <gmann> ^^ this is original discussion
06:35:08 <gmann> for me flat representation in both request and response with policy_name as string, policy_rules as dict seems good idea
06:35:24 <yikun> flat vs nest example in here: http://paste.openstack.org/show/725526/
06:35:25 <alex_xu> I need to read those discussion
06:35:33 <gmann> sure,
06:36:00 <gmann> plan is once we get agreement on thsoe, then yikun can update the spec also to reflect those changes
06:36:34 <gmann> yikun: anything else you want to discuss or we cna move next
06:37:20 <alex_xu> yikun: for "rules": {"max_server_per_host": 3}, do you mean "rules": "{"max_server_per_host": 3}"
06:37:29 <alex_xu> the value of rules is a string?
06:37:57 <alex_xu> yikun: sorry, I missed understand that, just ignore me
06:38:46 <yikun> don't worry, you could take a look on example http://paste.openstack.org/show/725526/
06:39:17 <yikun> gmann: only these 2 questions for me. :)
06:39:39 <gmann> flat2 should have policy_rules than rules_name
06:39:48 <gmann> like you doing in gerrit
06:40:37 <yikun> ha,yeah, typo
06:40:46 <gmann> ok
06:41:35 <gmann> alex_xu: you want to reply on patch. and we move next ?
06:41:40 <yikun> http://paste.openstack.org/show/725528/
06:41:46 <yikun> new one
06:41:48 <alex_xu> gmann: yea, I will try to review the patch first
06:42:05 <gmann> yikun: thanks
06:42:05 <yikun> alex_xu: gmann ok, thanks
06:42:08 <gmann> alex_xu: ok
06:42:48 <gmann> only things with new flat format is we need to do validation in code for policy_rules only requested for  "anti-affinity" otherwise 400
06:42:52 <gmann> but that should be ok.
06:42:58 <gmann> let's move next
06:43:08 <gmann> 4. Volume multiattach enhancements:
06:43:40 <gmann> matt mentoined in ML that he will be working on this.
06:43:46 <gmann> once it is ready we can add in our review list
06:44:29 <gmann> i forgot to mention that yikun BP in in nova runway this week and good to get this in
06:44:58 <gmann> Kevin_Zheng BP is in for next week so good to review it early and make it in good shape
06:45:07 <gmann> 5. API Extensions merge work
06:45:21 <gmann> #link https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-rocky
06:45:25 <openstackgerrit> OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/578019
06:45:49 <gmann> i do not have progress in this BP during this week.
06:46:06 <gmann> i will update current patch and push more during end of week
06:46:47 <gmann> last one matt mentioned in ML is handling cell down
06:46:48 <gmann> #link https://review.openstack.org/#/c/557369/
06:47:11 <gmann> i have note read the spec yet but if any of you want to give more feedback there
06:47:30 <gmann> note->not
06:48:05 <gmann> anything else on priority item otherwise we move to bug triage things
06:49:02 <gmann> let' move then
06:49:05 <gmann> #topic Bug Triage/Discussion
06:49:14 <gmann> #link https://etherpad.openstack.org/p/nova-api-weekly-bug-report
06:49:23 <gmann> i updated the weekly bug report
06:49:43 <gmann> there is not much change in that except i triaged 1 bug.
06:50:08 <gmann> we discussed to keep reviewing 2-3 in-progress bugs patches every week.
06:50:17 <gmann> which i did not do. :(
06:50:22 <alex_xu> hah
06:50:36 <gmann> alex_xu: how about you ?
06:50:37 <alex_xu> I only review one, and not finish yet
06:50:42 <alex_xu> #link https://review.openstack.org/#/c/486850/6
06:50:53 <alex_xu> thinking of we can make this move on
06:51:17 <gmann> ohk.
06:51:22 <alex_xu> Kevin_Zheng: it is your patch, I'm still thinking we should use environ variable to build a correct url instead of strip the url
06:51:27 * gmann forget about this
06:51:30 <alex_xu> strip the url is too hacky
06:52:08 <Kevin_Zheng> already forgot details about that one :)
06:52:33 <alex_xu> hah
06:53:16 <alex_xu> use the bug report example. the req.environ['PATH_INFO'] can get '/v2.0', and the req.environ['SCRIPT_NAME'] can get '/compute'.
06:53:47 * gmann our home work of cleaning up the in-progress patches is good idea to keep reminding the old work :)
06:55:16 <alex_xu> we should be able to figure which part of url is base url
06:56:42 <alex_xu> Kevin_Zheng: it is ok we can continue the discussion in the patch, since you need remember the detail
06:57:00 <Kevin_Zheng> yeah, I have to read it again
06:57:08 <gmann> yea, i think we can recall on patch and continue
06:57:43 <gmann> i will do more in-progress review before next office hour
06:58:19 <gmann> 3 min left
06:58:29 <gmann> anything on bug discussion?
06:59:00 <gmann> let's move to open in case of anything else
06:59:03 <gmann> #topic Open Discussion
06:59:28 <gmann> any more things to bring up  ?
06:59:59 <Kevin_Zheng> nope
07:00:15 <gmann> ok let's close the meeting then .
07:00:28 <gmann> thanks everyone for joining. good to see more people in API discussion :)
07:00:40 <gmann> #endmeeting