06:02:24 <gmann> #startmeeting nova api
06:02:25 <openstack> Meeting started Wed Jul 25 06:02:24 2018 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:02:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:02:28 <openstack> The meeting name has been set to 'nova_api'
06:02:39 <gmann> PING List: gmann, alex_xu
06:02:45 <gmann> who all here today
06:08:04 <Kevin_Zheng> o/
06:08:12 <gmann> Kevin_Zheng: hi
06:08:21 <Kevin_Zheng> :)
06:08:45 <gmann> seems like 2 of us. let's wait couple of min
06:08:55 <alex_xu> o/
06:09:09 <gmann> alex_xu: hi
06:09:17 <alex_xu> gmann: good afternoon
06:09:25 <gmann> good afternoon
06:10:32 <gmann> let's start
06:10:52 <gmann> #topic Priorities
06:11:11 <gmann> #link https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
06:11:13 <gmann> L57
06:11:23 <openstackgerrit> Rajesh Tailor proposed openstack/nova master: Fix host validity check for live-migration  https://review.openstack.org/401009
06:11:32 <gmann> 1. Servers Ips non-unique network names
06:11:49 <gmann> this one is no progress. i did not get time to start this due to extensions merge work
06:12:06 <gmann> which mean this would not go in Rocky. and we need to carry this to Stein
06:13:15 <gmann> 2.Abort live migration in queued state:
06:13:25 <gmann> this is done, thanks Kevin_Zheng
06:13:35 <gmann> 3. Complex anti-affinity policies:
06:13:55 <gmann> this is also done, thanks yikun
06:14:13 <gmann> 4. Volume multiattach enhancements:
06:14:31 <gmann> this is on same state. and most probably will be stein one
06:15:30 <gmann> 5. API Extensions merge work
06:15:44 <gmann> this is partially done
06:16:14 <gmann> part-1 schema merge - Completed
06:16:15 <gmann> part-2 server_create merge - last patch on gate
06:16:52 <alex_xu> gmann: so we just done the server_create merge in Rocky, right?
06:17:11 <gmann> alex_xu: yes, last patch is on gate -
06:17:13 <gmann> #link https://review.openstack.org/#/c/583882/2
06:17:19 <gmann> trying to get this in
06:17:45 <gmann> alex_xu: part-3 merging the view builder is left to merge. I have many of them up for review
06:18:05 <gmann> #link https://review.openstack.org/#/q/topic:bp/api-extensions-merge-rocky+status:open
06:18:22 <gmann> which will be in Stein i think.
06:18:31 <gmann> alex_xu: ?
06:18:52 <alex_xu> gmann: yea, just as mriedem said
06:19:13 <gmann> yeah, it is too late to merge them and gate also not so good since last week
06:19:41 <gmann> none of them are reviewed so i do not think they can make it
06:19:54 <gmann> alex_xu: today is FF or tomorrow ?
06:20:05 <alex_xu> tomorrow, our evening
06:20:13 <gmann> ok
06:20:50 <gmann> i have left for 3 patch to push to complete it but at least 6-7 total are left for review
06:21:32 <vishakha> gmann, Hi, i've been working on the bug https://bugs.launchpad.net/nova/+bug/1644457 but i found out that key_pair is a special case in which in_use remains always 0 as seen here https://github.com/openstack/nova/blob/master/nova/quota.py#L189
06:21:32 <openstack> Launchpad bug 1644457 in OpenStack Compute (nova) "keypair quota error" [Medium,Confirmed] - Assigned to Vishakha Agarwal (vishakha.agarwal)
06:21:49 <gmann> 7 up for review + 5 remaining to push
06:22:11 <gmann> vishakha: ok, let's discuss that during bug topic
06:22:27 <gmann> alex_xu: so we make final to postponed view builder to stein?
06:23:00 <alex_xu> gmann: yea, I think so, there are a lot of view builder, right?
06:23:15 <alex_xu> #link https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)
06:23:24 <alex_xu> ^this one is looking for your view builder change
06:23:50 <gmann> yeah, that makes this series easy
06:23:59 <vishakha> gmann, ok
06:24:20 <gmann> alex_xu:  total 12 patches to get in (7 up for review  + 5 need to push)
06:24:47 <alex_xu> gmann: doesn't sound we can make it in one day
06:25:08 <gmann> alex_xu: yes, not possible.
06:25:41 <gmann> alex_xu: ok i will postponed them to stein.  and will push them soon so that we can merge them early in stein
06:27:34 <gmann> and on same topic mriedem had query regarding moving the buildling of create_kwargs into helper method than in create() itself which makes it huge
06:27:56 <gmann> and deprecating the extensions policy which we already done in queens and i will remove them in stein
06:29:05 <gmann> moving the building of create_kwargs into helper can be discussed in stein as this is late to change them now in Rocky
06:30:15 <gmann> alex_xu: i am not sure we should open another specless BP for stein or just merge them as it is. anyways Rocky BP needs to be closed anyways.
06:30:34 <gmann> may be melwitt mriedem can suggest ^^
06:32:26 <alex_xu> gmann: yea, that should be a question for them
06:32:32 <gmann> ok
06:32:54 <gmann> let's move next
06:32:55 <gmann> 6. Handling a down cell
06:33:08 <gmann> #link https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)
06:33:34 <gmann> actually i am not following this one. alex_xu you know if that is target for Rocky i mean can it make it by tomorrow ?
06:34:29 <alex_xu> gmann: sounds like target to Rocky, at least we have spec for rocky http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/handling-down-cell.html
06:34:37 <gmann> yeah
06:34:41 <alex_xu> gmann: but looks like it starts very late
06:35:05 <gmann> i saw mriedem comment of doing service list change also in same microversion of server list - #link https://review.openstack.org/#/c/584829/
06:35:45 <gmann> yea it is started late like me :) i also did start the extensions work too late due to QA things.
06:36:03 <gmann> anyways let's see how far it will go tomorrow
06:36:37 <gmann> that is all Rokcy items
06:37:00 <gmann> next may be after FF, we can keep eyes on API bugs and Stein specs for review
06:37:02 <gmann> #link https://review.openstack.org/#/q/project:openstack/nova-specs+status:open+message:%22apiimpact%22
06:37:46 <gmann> that's all on priority, anything else to discuss otherwise we move to bug discussion
06:39:19 <gmann> seems no. let's move then
06:39:26 <gmann> #topic Bug Triage/Discussion
06:39:47 <gmann> #link https://etherpad.openstack.org/p/nova-api-weekly-bug-report
06:40:34 <gmann> curren total open bugs are 68.
06:40:44 <Kevin_Zheng> omg
06:41:08 <gmann> honestly saying i was getting less time for bugs due to extensions work but after FF i will give more time on this to burn it down to less
06:42:00 <gmann> 34 out of them are in-progress
06:42:20 <gmann> vishakha: you wanted to discuss some bug?
06:44:27 <vishakha> gmann, yes
06:44:30 <alex_xu> vishakha: can you reproduce it in master? the bug is reported in newton, and we change quota a lot recently, like we remove the commit, rollback stuff for cellv2
06:44:48 <vishakha> gmann, Hi, i've been working on the bug https://bugs.launchpad.net/nova/+bug/1644457 but i found out that key_pair is a special case in which in_use remains always 0 as seen here https://github.com/openstack/nova/blob/master/nova/quota.py#L189
06:44:48 <openstack> Launchpad bug 1644457 in OpenStack Compute (nova) "keypair quota error" [Medium,Confirmed] - Assigned to Vishakha Agarwal (vishakha.agarwal)
06:45:17 <gmann> alex_xu: it seems key_pairs is in special case for in_use always 0
06:45:18 <gmann> #link https://github.com/openstack/nova/blob/master/nova/quota.py#L189
06:45:39 <vishakha> gmann, I have a doubt  when adding a key to instance. It should come in 'in_use' of quota_usage?
06:48:11 <gmann> vishakha: is it reproducible on master as alex_xu asked
06:48:42 <vishakha> gmann, yes it is
06:49:28 <vishakha> alex_xu, the 'in_use' for keypair is coming 0 always
06:51:40 <alex_xu> interesting...
06:52:55 <alex_xu> I thought it should call this https://github.com/openstack/nova/blob/master/nova/quota.py#L1244
06:55:39 <alex_xu> vishakha: the `nova quota-show --detial` should show 0, but `nova quota-show --detail --user {user_id}` indeed should show the usage as my understand
06:56:26 <alex_xu> vishakha: I'm not sure whether https://github.com/openstack/nova/blob/master/nova/quota.py#L189 missing a check for the user_id isn't None
06:57:30 <gmann> yeah, db count id per user - https://github.com/openstack/nova/blob/e019be3724d949b1239c2cc3fbc00f1f69a3477c/nova/db/sqlalchemy/api.py#L3043
06:57:48 <gmann> s/id/it
07:02:30 <vishakha> alex_xu, gmann : I have tried with --user parameter also, still showing 0 in_use
07:03:10 <gmann> alex_xu: i found some context of doing it intentionally or say as per old behaviour
07:03:14 <gmann> alex_xu: #link https://review.openstack.org/#/c/446239/3/nova/tests/unit/test_quota.py@1031
07:05:38 <alex_xu> gmann: interesting
07:07:44 <gmann> may be we can fix that per user but sot sure we can fix it easily as melwitt metnioned on that reivew
07:07:59 <alex_xu> gmann: it sounds make sense to show keypair for specific user, but for the server_group_member we really have no way to express that
07:08:26 <gmann> yeah that per server group
07:09:18 <alex_xu> gmann: then do we need microversion :)
07:09:28 <gmann> humm
07:10:32 <gmann> it change the behaviour but not sure we need microversion as it would not cause any backward incompatibility in iterface usage
07:11:20 <alex_xu> gmann: but there is no way for the user to know whether the usage is valid in the deployment
07:12:02 <sean-k-mooney> mriedem: melwitt regarding the noop plugin im just looking into it now. it looks related to how we dynamicaly load plugins here https://github.com/openstack/os-vif/blob/master/os_vif/__init__.py#L41-L49
07:12:16 <sean-k-mooney> mriedem: melwitt ill take a look at it now
07:12:22 <gmann> yeah, that's true.
07:13:43 <gmann> microversion bump can be done but then it cannot be backported if we want to.
07:14:17 <alex_xu> gmann: we have user quota since long time ago, not sure whether is it always 0
07:14:42 <alex_xu> gmann: this bug is newton
07:15:19 <alex_xu> gmann: or just send this question to maillist to get wider agreement
07:15:32 <alex_xu> I'm really not good at answering the microversion question
07:16:13 <gmann> alex_xu: you mean to ask for microversion bump or to fix the bug for showing the key_pair usage per suer ?
07:17:02 <alex_xu> gmann: both I guess since we already ask question, at least it make sense to show user qutoa for keypair for me
07:17:44 <gmann> alex_xu: ok.
07:18:18 <gmann> i can send the ML, tough i do not have full context of quota calculation background
07:18:29 <gmann> s/tough/though
07:18:54 <alex_xu> I can help that
07:20:13 <gmann> alex_xu: thanks,
07:20:29 <gmann> alex_xu: you mean you can send mail or reply on the query i sent?
07:21:13 <alex_xu> gmann: ethier works for me :)
07:22:04 <alex_xu> s/ethier/either/
07:22:20 <gmann> alex_xu: cool, I will bring the query on ML and then you can respond.  thanks
07:22:27 <alex_xu> gmann: got it, thanks
07:22:30 <gmann> anything else on bug or we move next
07:22:45 <gmann> #topic Open Discussion
07:23:00 <vishakha> gmann, should I look for another?
07:23:20 <gmann> vishakha: sorry did not conclude that. we are bringing your question on ML and their you can see the discussion or respond
07:23:43 <vishakha> gmann, alex_xu : ok thanks
07:23:56 <gmann> vishakha: yeah, if you can help on other bug also it will be great. if you are looking for more then you can choose from API one
07:24:11 <gmann> vishakha: #link
07:24:11 <gmann> https://bugs.launchpad.net/nova/+bugs?field.searchtext=&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=api%20api-ref&field.tags_com
07:24:11 <gmann> binator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search&orderby=-importance&start=0
07:24:16 <gmann> opps
07:24:22 <vishakha> gmann, yes sure
07:24:32 <gmann> anything else to discuss or we close the office hour
07:25:01 <gmann> let's close then.
07:25:04 <vishakha> gmann, just wanted you to review https://review.openstack.org/#/c/580271/
07:25:05 <Kevin_Zheng> me
07:25:12 <gmann> Kevin_Zheng: go ahead
07:25:30 <Kevin_Zheng> Our product team found out a strange API behaviour
07:25:31 <Kevin_Zheng> https://developer.openstack.org/api-ref/compute/#get-availability-zone-information
07:25:36 <gmann> vishakha: sure, ll add in my list
07:25:41 <Kevin_Zheng> there is a hosts field
07:25:55 <Kevin_Zheng> and it will always be "null"
07:26:02 <Kevin_Zheng> it was just added here:
07:26:14 <Kevin_Zheng> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/availability_zone.py#L42
07:26:26 <Kevin_Zheng> so any particular reason why it is added?
07:26:34 <Kevin_Zheng> Or should we just remove it
07:27:53 <gmann> Kevin_Zheng: may be for consistency for GET and GET detail API
07:28:05 <gmann> Kevin_Zheng: Detail give the host information
07:28:09 <vishakha> gmann, Thanks :)
07:28:19 <Kevin_Zheng> but do we need this kind of consistency?
07:28:23 <Kevin_Zheng> looks strange
07:28:33 <gmann> #link https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/availability_zone.py#L91
07:28:42 <Kevin_Zheng> we do not have this kind of consistency in list server and list server details
07:29:17 <Kevin_Zheng> yeah, I know that, just think this is not necessary
07:29:22 <gmann> ohk it is not get particular AZ
07:29:49 <gmann> we can remove but need microversion. what harm in keeping it ?
07:30:15 <Kevin_Zheng> no harm, just found it strange
07:30:21 <Kevin_Zheng> and the customer asks
07:30:37 <Kevin_Zheng> so we have to tell them why it is like that all the time
07:30:48 <gmann> i remember we kept it for v2.1 for compatibility
07:31:12 <Kevin_Zheng> So might be good to remove it in S?
07:31:18 <Kevin_Zheng> with microversion
07:32:01 <gmann> Kevin_Zheng: ok. i can note down this on API improvement etherpad  (which i need to create yet)and then we can decide if we can fix this with other consistent changes
07:32:15 <Kevin_Zheng> yeah cool
07:32:26 <gmann> microversion alone for this seems little overhead for me
07:32:39 <Kevin_Zheng> yeah
07:33:04 <gmann> Kevin_Zheng: thanks for finding and reporting this.
07:33:29 <Kevin_Zheng> NP, just solving our problems
07:33:44 <gmann> anything else to discuss
07:34:29 <gmann> ok let's close then
07:34:35 <gmann> thanks everyone for joining
07:34:39 <gmann> #endmeeting