| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-28 | |||
| 11:05:16 | bauzas | see the above patch https://review.opendev.org/723858 | |
| 11:05:34 | bauzas | so the problem is not related to cyborg but rather for all nested resource providers | |
| 11:06:37 | bauzas | anyway, not a RC regression given we had the same issue in Train for vGPUs (and possibly bandwidth-aware instances,wdyt gibi ?) | |
| 11:16:31 | gibi | bauzas: thanks for the reporoduction | |
| 11:25:03 | brinzhang_ | gibi: my partner proposed a bug, see https://bugs.launchpad.net/nova/+bug/1875624 | |
| 11:25:03 | openstack | Launchpad bug 1875624 in OpenStack Compute (nova) "the vms can not be force deleted when vm_status is soft-delete and task-state=deleting" [Undecided,New] - Assigned to xuyuanhao (thourch) | |
| 11:25:08 | brinzhang_ | gibi: can you check | |
| 11:25:20 | gibi | brinzhang_: will check soon | |
| 11:25:27 | brinzhang_ | gibi: thanks | |
| 11:40:38 | gibi | brinzhang_: confirmed the bug. | |
| 12:30:37 | bauzas | gibi: brinzhang: FWIW, I think we should change the title of bug 1874664 to make it clear it's for all nested Resource Providers | |
| 12:30:37 | openstack | bug 1874664 in OpenStack Compute (nova) "Boot more than one instances failed with accelerators in its flavor" [Medium,Confirmed] https://launchpad.net/bugs/1874664 - Assigned to Wenping Song (wenping1) | |
| 12:30:37 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add nested resource providers limit for multi create https://review.opendev.org/723884 | |
| 12:31:01 | gibi | bauzas: I agree | |
| 12:32:59 | bauzas | changed https://bugs.launchpad.net/nova/+bug/1874664 | |
| 12:32:59 | openstack | Launchpad bug 1874664 in OpenStack Compute (nova) "Instance multi-create doesn't support available resources spread between children RPs" [Medium,Confirmed] - Assigned to Wenping Song (wenping1) | |
| 12:33:35 | bauzas | gibi: have you tested it for bandwidth-aware instances ? | |
| 12:33:52 | bauzas | actually, that's traits, right? | |
| 12:34:35 | gibi | bauzas: multi create with neutron ports are not supported even without bandwidth | |
| 12:34:50 | gibi | multi create with neutron net is supported without bandwidth | |
| 12:35:00 | bauzas | ack ok | |
| 12:35:33 | bauzas | fwiw, multi-create works with vGPUs if one RP has all the capacity for all the instances | |
| 12:35:49 | brinzhang_ | bauzas, gibi: I am now confused (dazzled) ^^ | |
| 12:36:02 | bauzas | and I guess it's the same for cyborg resources | |
| 12:36:47 | gibi | brinzhang_, bauzas: I have to jump on a call, sorry. I will read back later | |
| 12:36:52 | brinzhang_ | bauzas: you mean change "Add" to "All"? | |
| 12:38:09 | brinzhang_ | bauzas: if possiable, you can edit that patch, or you can leave comments inline, I have to go home now, it's too later for me, I am sorry | |
| 12:38:47 | brinzhang_ | gibi, bauzas: thanks ^^ | |
| 12:40:54 | bauzas | brinzhang: see the bug description modification https://bugs.launchpad.net/nova/+bug/1874664 | |
| 12:40:54 | openstack | Launchpad bug 1874664 in OpenStack Compute (nova) "Instance multi-create doesn't support available resources spread between children RPs" [Medium,Confirmed] - Assigned to Wenping Song (wenping1) | |
| 12:47:14 | brinzhang_ | bauzas: I think that use you write in bug description in my patch | |
| 12:47:20 | brinzhang_ | it looks better | |
| 12:47:30 | brinzhang_ | an easy to understand | |
| 12:47:36 | brinzhang_ | s/an/and | |
| 13:01:01 | AJaeger | The nova ussuri translations are at https://review.opendev.org/723160, any stable nova core to import them, please? | |
| 13:02:46 | nightmare_unreal | can someone review this : https://review.opendev.org/#/c/715395/ Thanks | |
| 13:18:12 | elod | AJaeger: about https://review.opendev.org/723160 : if I understand correctly it is safe to merge now and don't really need any extra review. Am I right? | |
| 13:20:05 | AJaeger | elod: it's safe to merge now and most projects have single core review. | |
| 13:20:15 | AJaeger | elod: let me grab you a link for the safe... | |
| 13:21:28 | AJaeger | elod: http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014437.html has "For projects with translations, watch for any translation patches coming through and merge them quickly" | |
| 13:21:57 | elod | AJaeger: thanks! reading | |
| 13:23:41 | elod | ohh, the release countdown mail, i see, thanks | |
| 13:23:52 | AJaeger | yep, that one | |
| 13:24:55 | elod | AJaeger: approved | |
| 13:30:36 | artom | stephenfin, any chance I could get you to revisit https://review.opendev.org/#/c/687404/20 ? | |
| 13:41:12 | AJaeger | thanks, elod | |
| 13:43:23 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova stable/train: Add default cpu model for AArch64 https://review.opendev.org/723900 | |
| 13:48:23 | elod | well, thanks for calling my attention to that patch. I've already had a look at it, but saw that zuul was in bad shape so waited for zuul to get back to normal | |
| 13:53:19 | stephenfin | artom: sure | |
| 14:04:49 | kashyap | s/fatique/fatigue/ | |
| 14:17:33 | artom | stephenfin, thanks :) | |
| 14:21:05 | gmann | gibi: thanks, i added comment. i think changing 'oslopolicy-sample-generator' depends how we change it, say adding deprecated rules by default or based on request. because there might be operator who are using this tool for no-deprecated-rules usage | |
| 14:22:18 | gmann | which was the only way to move to new defaults and stop old token to pass via deprecated rule until we introduced new flag in oslo.policy 'oslo_policy.enforce_new_defaults' | |
| 14:22:21 | stephenfin | dansmith: Now that we've branched, could you take a look at https://review.opendev.org/#/c/537414/ and https://review.opendev.org/#/c/530905/ again? | |
| 14:23:12 | gmann | may be bnemec and stephenfin can input how we can accommodate both use case of 'oslopolicy-sample-generator' here. | |
| 14:23:39 | gmann | i mean adding deprecated based on request can be done but if it solve the zigo case. | |
| 14:23:43 | dansmith | stephenfin: ack | |
| 14:23:49 | stephenfin | dansmith: ta | |
| 14:23:57 | dansmith | gmann: I thought it was said that the generator wasn't going to get that new mode | |
| 14:24:00 | dansmith | or at least, not in time | |
| 14:25:17 | gmann | dansmith: yeah that was my understanding but gibi opinion is to do that if we can. | |
| 14:25:28 | bnemec | I'm not a big fan of adding a feature to support an anti-pattern in deploying OpenStack. | |
| 14:26:03 | stephenfin | Could we just handwrite a policy.json file and include it in our sdist for this release? | |
| 14:26:17 | dansmith | gmann: the problem I see is that the oslo tool will not do that by default, but our default in nova is to need the deprecated rules, | |
| 14:26:25 | stephenfin | zigo could consume that instead of using the oslopolicy tool | |
| 14:26:29 | gmann | we have to carefully things of way for operator to move to new defaults was only overwrite the rule in policy file which is this case we taken as broken | |
| 14:26:34 | dansmith | so we're requiring a lot of people to know to disable one default and override another, to get a consistent set of defaults that will work | |
| 14:27:06 | artom | stephenfin, thanks :) | |
| 14:27:08 | gmann | exactly | |
| 14:27:16 | artom | dansmith, https://review.opendev.org/#/c/672595/73 pretty please? When your queue gets to it | |
| 14:27:35 | dansmith | stephenfin: I think that's more obscure for people that aren't already looking for a sample file, but maybe easier to get themselves out of the hole once they realize they've deployed and screwed themselves up | |
| 14:28:04 | dansmith | artom: ack | |
| 14:31:17 | gmann | gibi: I will update the patch for reno comments and will keep bug open. and we can discuss the best possible approach about policy file usage in cross project sessions in PTG what bnemec added in oslo etherpad and i linked in nova ptg ethrepad too. | |
| 14:32:10 | gmann | gibi: zigo that works for you ^^ ? | |
| 14:35:41 | dansmith | stephenfin: oh right, yeah I'm not going to approve those completely inconsistent style things in the middle of a file, but I'm sure someone else will | |
| 14:36:06 | stephenfin | huh? | |
| 14:37:03 | dansmith | the "black says this ugly style is cool, so I'll just break from the rest of nova conventions here for the new code I'm adding" thing in your tests | |
| 14:37:39 | stephenfin | um, those are entirely new tests? | |
| 14:37:56 | dansmith | in a file with a style, in a project with a style | |
| 14:38:29 | stephenfin | really? | |
| 14:38:47 | dansmith | you're not even consistent within those tests | |
| 14:39:10 | stephenfin | we're inconsistent all over the place | |
| 14:39:17 | stephenfin | you're not going to hammer me for style, surely? | |
| 14:43:26 | artom | stephenfin, dansmith, hey, I may be late to the party, but those .contains("nova_object.name") searches... | |
| 14:43:38 | artom | This kind of substring search is notoriously slow in SQL, no? | |
| 14:43:52 | artom | For the compute nodes, it's probably fine, since there aren't that many of them, but for instances... | |
| 14:43:58 | dansmith | artom: they're not indexed, so yes | |
| 14:45:00 | artom | So we're just accepting that? | |
| 14:45:46 | artom | I dunno if that's been talked about before, as I said, I'm late to the party | |
| 14:46:05 | stephenfin | I don't think we've a choice. There's no other heuristic we can use to differentiate the legacy entries from the non-legacy ones | |
| 14:46:17 | dansmith | I guess if we did it in python, despite being slower, it's load on the machine running the nova-manage, instead of the DB server itself, which is probably better | |
| 14:47:39 | dansmith | although maybe we'd have no filter at that point and basically return all the instances | |
| 14:47:43 | dansmith | so yeah I dunno | |
| 14:49:21 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645 | |
| 14:49:40 | gmann | dansmith: gibi zigo updated , please check - https://review.opendev.org/#/c/723645/ | |
| 14:50:30 | artom | dansmith, stephenfin, I guess there's no way to do "pagination" when selecting instance_extra? | |
| 14:50:48 | dansmith | artom: what would that help? | |
| 14:51:29 | artom | dansmith, select all instance_extra in steps of 100 or whatever, do the filtering in Python, find the instance UUIDs that way, then with those go back to the database? | |
| 14:52:58 | artom | Apparently you can do stuff with LIMIT: https://stackoverflow.com/questions/3799193/mysql-data-best-way-to-implement-paging | |
| 14:53:02 | dansmith | artom: but we'd still end up selecting every instance out of the database every time right? | |