| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-30 | |||
| 01:20:06 | openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: YAML file loading and schema validation https://review.opendev.org/673341 | |
| 02:44:13 | openstackgerrit | Brin Zhang proposed openstack/nova master: cyborg evacuate support https://review.opendev.org/715326 | |
| 02:44:13 | openstackgerrit | Brin Zhang proposed openstack/nova master: Optimize _create_and_bind_arqs logic in conducor https://review.opendev.org/726564 | |
| 03:48:41 | openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: Function to further validate and retrieve configs https://review.opendev.org/676029 | |
| 07:39:30 | openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: YAML file loading and schema validation https://review.opendev.org/673341 | |
| 07:39:31 | openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: Function to further validate and retrieve configs https://review.opendev.org/676029 | |
| 07:51:56 | bauzas | stephenfin: not sure you got a chance to see my comment https://review.opendev.org/#/c/743568/1/nova/virt/libvirt/migration.py@128 | |
| 07:53:24 | tony_su | stephenfin: the first patch is uploaded and in almost-completed phase, and the second patch is ready for a new round of review. | |
| 08:24:44 | brinzhang0 | sean-k-mooney: please see https://review.opendev.org/#/c/715326/15/nova/compute/manager.py@3233, I agree with gibi, can we remove the eventlet.timeout.Timeout Exception? | |
| 08:55:40 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Rebase qcow2 images when unshelving an instance https://review.opendev.org/696084 | |
| 08:59:41 | openstackgerrit | Jie Li proposed openstack/nova-specs master: add volume backed server rebuild spec https://review.opendev.org/739349 | |
| 10:12:48 | sean-k-mooney | brinzhang0: i am not sure, i think it could be raised form any https request but if we remove it and it is raised it will still be caught by the generic Exception | |
| 10:13:01 | sean-k-mooney | specifier | |
| 10:13:10 | sean-k-mooney | so it wont change behavior to remove it | |
| 10:13:19 | sean-k-mooney | so we could for brevity | |
| 11:01:31 | openstackgerrit | Harshavardhan Metla proposed openstack/nova master: Removed the host FQDN from the exception message https://review.opendev.org/743950 | |
| 12:19:39 | gibi_pto | dansmith: I've did a quick cleanup on the todays meeting agenda on the wiki for you | |
| 13:23:20 | dansmith | gibi_pto: roger, thanks, I was just going to look at it this morning | |
| 13:30:09 | openstackgerrit | Andrew Bonney proposed openstack/nova master: Fix misleading documentation for live_migration_inbound_addr https://review.opendev.org/741473 | |
| 13:34:02 | bauzas | dansmith: I guess you'll handle the v-2 tag ? | |
| 13:34:20 | dansmith | bauzas: apparently there's nothing to do, we worked that out last week I think | |
| 13:34:31 | bauzas | mmmm really ? | |
| 13:34:37 | bauzas | lemme doublecheck | |
| 13:34:49 | dansmith | according to smcginnis, but if he tells me to do something I'll do it | |
| 13:36:01 | bauzas | dansmith: can't see any nova proposed change in the releases repo | |
| 13:36:08 | bauzas | for victoria-2 I mean | |
| 13:37:36 | bauzas | actually, nevermind | |
| 13:37:41 | dansmith | let's wait for smcginnis to respond | |
| 13:37:50 | bauzas | can't see any service project change for victoria-1 either | |
| 13:37:56 | bauzas | so I guess it changed | |
| 13:38:54 | bauzas | yeah, that changed and I now remember ttx's email on openstack-discuss https://releases.openstack.org/reference/release_models.html#cycle-with-milestones | |
| 13:39:09 | bauzas | we no longer produce milestones, only rcs | |
| 13:41:02 | bauzas | ... and confirmed here https://releases.openstack.org/reference/process.html#milestone-2 | |
| 14:04:44 | smcginnis | Yep, no release needed now unless you know there is some downstream need for it. | |
| 14:09:27 | kashyap | fungi++ | |
| 14:10:04 | fungi | am i now an object-oriented compiled language? | |
| 14:11:05 | fungi | fungi99 was more flexible, even if you wound up with a lot more templating and boilerplate | |
| 14:11:41 | fungi | though my heart still belongs to classic k&r fungi | |
| 14:47:53 | ralonsoh | stephenfin, hi again | |
| 14:47:54 | ralonsoh | https://review.opendev.org/#/c/739961/ | |
| 14:48:03 | ralonsoh | if you have a bit of time | |
| 14:52:09 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: DNM: testing tempest copy-image test https://review.opendev.org/742547 | |
| 14:55:41 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: DNM: testing tempest copy-image test https://review.opendev.org/742547 | |
| 14:59:11 | stephenfin | ralonsoh: How do you plan to use these traits? That's still not entirely clear to me | |
| 14:59:41 | sean-k-mooney | stephenfin: we will need nova changes next cycle to report the traits | |
| 14:59:41 | ralonsoh | stephenfin, if needed, that will be enforced in the port info | |
| 14:59:48 | stephenfin | what resource providers will they be reported on, and who sets them? | |
| 14:59:54 | ralonsoh | let me check where exactly | |
| 15:00:30 | sean-k-mooney | stephenfin: initally they will be reported on the compute node root rp if either sriov is enabled or numa vswitches | |
| 15:00:56 | ralonsoh | stephenfin, https://review.opendev.org/#/c/740011/4/specs/victoria/port-numa-affinity-policy.rst@70 | |
| 15:01:03 | ralonsoh | is this what you are asking? | |
| 15:01:03 | sean-k-mooney | stephenfin: if we start tracking pci device in plamcnet then it will be on the pci device RP | |
| 15:01:08 | stephenfin | ah, there's a spec. That's what I was looking for | |
| 15:02:21 | ralonsoh | but yes, we are not pointing to any specific RP | |
| 15:04:12 | stephenfin | this doesn't feel like a trait or something you'd want to report | |
| 15:04:42 | ralonsoh | stephenfin, ? | |
| 15:04:52 | stephenfin | so with this feature, we're saying you'll be able to state whether NUMA affinity is important or not on a port-by-port basis | |
| 15:05:05 | sean-k-mooney | yes | |
| 15:05:06 | ralonsoh | yes | |
| 15:05:10 | stephenfin | cool, so what do we need the trait for | |
| 15:05:21 | ralonsoh | to specify the policy | |
| 15:05:22 | sean-k-mooney | to select host that supprot numa affinity | |
| 15:06:02 | stephenfin | that's a single trait, not three | |
| 15:06:05 | sean-k-mooney | stephenfin: its mostly required for numa_vswitchs | |
| 15:06:14 | stephenfin | SUPPORTS_CONFIGURABLE_NUMA_AFFINITY | |
| 15:06:20 | stephenfin | or something like that | |
| 15:06:38 | sean-k-mooney | not really numa_vsiwtch only support stict affinity today | |
| 15:06:48 | sean-k-mooney | not all 3 | |
| 15:07:20 | sean-k-mooney | although we woudl be changing that as part of the nova half of the feature | |
| 15:07:33 | stephenfin | so it wouldn't report SUPPORTS_CONFIGURABLE_NUMA_AFFINITY | |
| 15:07:42 | stephenfin | (again, just a placeholder trait name) | |
| 15:08:05 | sean-k-mooney | stephenfin: perhaps but i think knowing which policy is support is imporant | |
| 15:08:26 | sean-k-mooney | im also expecting this to be resued for pmem and vgpus | |
| 15:08:31 | stephenfin | are there scenarios where we'd report each one of the traits by themselves? | |
| 15:08:51 | ralonsoh | only one per port | |
| 15:08:53 | sean-k-mooney | yes | |
| 15:09:03 | sean-k-mooney | maybe | |
| 15:09:16 | sean-k-mooney | i need to check if the numa policy is in the alias or pci white list | |
| 15:09:21 | stephenfin | ralonsoh: Sorry, my time's been split multiple different ways so I haven't gotten to sunk my teeth into this before now. Just teasing things out before we merge something we can't undo :) | |
| 15:09:23 | sean-k-mooney | if its in the whitelist then no | |
| 15:09:31 | sean-k-mooney | * alias | |
| 15:09:37 | ralonsoh | stephenfin, sure | |
| 15:10:41 | sean-k-mooney | ok so the numa policy is part of the alias https://github.com/openstack/nova/blob/master/nova/pci/request.py#L93 | |
| 15:11:03 | sean-k-mooney | so we dont need to cater for reporting device as only consumable with a singel policy | |
| 15:11:10 | sean-k-mooney | its not defiend in the whitelist | |
| 15:11:15 | stephenfin | right, though it's only done that way because aliases are as granular as we get | |
| 15:12:13 | stephenfin | we didn't (don't) have a mechanism to say use the PCI device indicated by this alias and don't worry about NUMA affinity | |
| 15:12:26 | sean-k-mooney | yes we do | |
| 15:12:44 | sean-k-mooney | oh you mean per alias | |
| 15:12:46 | stephenfin | the flavor extra spec applies to all PCI devices, not just one | |
| 15:12:48 | sean-k-mooney | right we dont | |
| 15:12:49 | stephenfin | yes | |
| 15:12:56 | stephenfin | right | |
| 15:13:28 | stephenfin | so that's still a TODO after this but we'll be able to do it for SR-IOV ports at least | |
| 15:13:46 | stephenfin | but the ability to do that smells like a simple binary capability | |
| 15:14:12 | sean-k-mooney | stephenfin: we kind of hoped to stop using the alias and move pci deivce to the top level api or use cyborg | |
| 15:14:21 | ralonsoh | but with this information in the port we don't need to limit that to sriov ports only | |
| 15:14:27 | sean-k-mooney | which is why it was not added orginally | |
| 15:14:37 | stephenfin | i.e. I allow you to configure NUMA affinity of individual resources or I don't | |
| 15:14:47 | sean-k-mooney | ralonsoh: right we are not | |