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