| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-25 | |||
| 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:47 | 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 | 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: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 | vishakha: #link | |
| 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? | |