Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-28
10:15:52 bauzas not the fake driver itself
10:15:57 gibi I see
10:16:36 gibi anyhow it is not burning hot issue right now and songwenping_ PoC seems to be a step in the good direction
10:17:52 gibi as soon as we have a func recreate for the accelerator case we can adapt that for the VGPU case as well (with the fake driver)
10:24:02 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Test multi create with vGPUs https://review.opendev.org/723858
10:24:08 bauzas gibi: ^
10:24:31 gibi bauzas: ack, I will look
10:24:57 bauzas gibi: I'll provide a new revision for it with testing what happens when you ask for 2 vGPUs in multicreate but each pGPU can only create one
10:25:14 kashyap lyarwood: Hi, I'm just digging into the Q35 failure with 'virt-preview': seems like the logs are already gone
10:25:19 gibi bauzas: OK
10:26:08 bauzas gibi: tbc, placement doesn't support sharding resources over RPs but here this is not the issue
10:26:13 kashyap lyarwood: I take it that you haven't had a chance to look at them I just did a 'recheck' for it to reun
10:26:17 kashyap s/reun/rerun/
10:27:45 gibi bauzas: yeah, if we have two instance requesting one VGPU each then we never allocate two VGPUs in the same placement request so no sharding is needed from placement
10:34:51 lyarwood kashyap: I haven't sorry
10:35:18 bauzas gibi: interesting, we don't have the problem for multi-create with vGPUs filling up capacity
10:39:19 openstackgerrit Sylvain Bauza proposed openstack/nova master: Test multi create with vGPUs https://review.opendev.org/723858
10:39:36 bauzas gibi: see above, I created two instances with 8 vGPUs each
10:39:54 kashyap yarwood: No problem; I'll dig in
10:42:27 bauzas oh snap
10:43:21 bauzas (I just ran the older test and now the new one)
10:45:40 bauzas ah, reproduced
11:04:32 openstackgerrit Sylvain Bauza proposed openstack/nova master: Test multi create with vGPUs https://review.opendev.org/723858
11:05:01 bauzas brinzhang: songwenping_: gibi: confirmed the issue for vGPUs
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?

Earlier   Later