| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-14 | |||
| 19:24:13 | bauzas | jaypipes: around ? | |
| 19:25:02 | bauzas | jaypipes: about https://review.openstack.org/#/c/557065/ | |
| 19:25:07 | mriedem | mnaser: agree with dan, single change with the config option added with choices is best, since it defaults to None it should be ok | |
| 19:25:07 | bauzas | good question ^ | |
| 19:27:30 | jaypipes | bauzas: yes? | |
| 19:27:49 | artom | I think with NUMA it's a bit different - in the sense that an instance can switch from file-backed to non-file backed, and the user might never now (latencies notwithstanding) | |
| 19:27:59 | bauzas | jaypipes: so, about your point, maybe we should have some aliases for PCI devices ? | |
| 19:28:20 | bauzas | like we did for PCI passthrought ? | |
| 19:29:01 | artom | For NUMA... an instance *has* a NUMA topology, and we can't get rid of it, so if both source and dest can't handle live migrating the instance NUMA topology, so to speak, it's fair to bail out | |
| 19:29:11 | bauzas | jaypipes: and then the compute would pass custom traits using those aliases ? | |
| 19:29:53 | bauzas | like CUSTOM_GPU_M608Q | |
| 19:32:06 | bauzas | mriedem: heh, btw. I just paid for a Huawei P20 Pro. Hope you'll get some money thanks to me :p | |
| 19:34:59 | zcorneli | dansmith: mriedem: Looking at check_can_live_migrate_destination, there doesn't look like anything in there actually fails out a migration, just collects data for the source to decide on. | |
| 19:35:34 | jaypipes | bauzas: why? | |
| 19:36:12 | jaypipes | bauzas: I mean, why would we create such a custom trait? | |
| 19:36:23 | jaypipes | bauzas: it doesn't mean anything. | |
| 19:36:30 | jaypipes | bauzas: it's just a vendor ID. | |
| 19:36:45 | mriedem | bauzas: i won't hold my breath | |
| 19:36:58 | jaypipes | bauzas: we should be putting the standard GPU traits in the flavor | |
| 19:37:48 | bauzas | jaypipes: maybe, I'm not specifically torn on that | |
| 19:38:09 | mriedem | zcorneli: you have to raise MigrationPreCheckError | |
| 19:38:16 | bauzas | jaypipes: tbc, the spec is for passing multiple vGPU types, but not on *asking* for a specific type | |
| 19:38:22 | artom | Unrelated logging question - if a method isn't passed a context, will LOG.debug still print the request ID? | |
| 19:38:35 | mriedem | zcorneli: this is an rpc call to the dest compute https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L222 | |
| 19:38:40 | bauzas | jaypipes: for that, I'd love to see Xen folks | |
| 19:38:50 | artom | I thought it did some black magic with the context, so if you're not passing it to a method, any LOG calls from within that method won't have the request ID | |
| 19:39:03 | mriedem | zcorneli: if we fail with MigrationPreCheckError we'll handle it here https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L337 and continue looking for another valid destination host | |
| 19:39:15 | bauzas | jaypipes: my point is that, for the moment, operators wanting to provide flavors for a specific type could just use placement-client and use custom traits, right? | |
| 19:39:19 | mriedem | artom: yes | |
| 19:39:31 | mriedem | artom: the context is stored in memory | |
| 19:39:42 | bauzas | jaypipes: so, the question you have is more about how nova could use standard traits, then | |
| 19:39:42 | mriedem | which causes all sorts of confusion wrt the request id | |
| 19:39:47 | jaypipes | bauzas: why would they do that, though? | |
| 19:40:00 | mriedem | artom: https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L40 | |
| 19:40:00 | bauzas | jaypipes: why what ? using custom traits ? | |
| 19:40:15 | bauzas | jaypipes: because custom traits already exist | |
| 19:40:25 | jaypipes | bauzas: the user wants a vGPU that has certain capabilities (resolution, max display heads, support for OpenCL, etc) | |
| 19:40:39 | bauzas | jaypipes: sure, I understand your point | |
| 19:40:45 | jaypipes | bauzas: the user doesn't want a specific M60-8Q Nvidia vGPU "type". | |
| 19:40:56 | bauzas | jaypipes: I don't disagree with that :) | |
| 19:40:56 | artom | mriedem, so there's a global context per thread? | |
| 19:41:06 | bauzas | jaypipes: tbh, I'm fine with that | |
| 19:41:36 | jaypipes | bauzas: when we discussed this with the Xen folks on the original VGPU spec, jianghuaw_ and I specifically agreed that vgpu "types" (which are nothing more than vendor jargon) would *not* be used as traits. | |
| 19:41:43 | bauzas | jaypipes: my plan was about passing aliases, but for sure, we could have other conf opts for saying : "this trait = that PCI id" | |
| 19:42:20 | bauzas | jaypipes: but like I said in my gerrit reply, I don't think it's related to the spec I wrote, maybe in a separate spec ? | |
| 19:42:37 | zcorneli | mriedem: Ah, ok, needed to look up one more layer. Thanks! | |
| 19:42:40 | bauzas | or we could opt something like "this PCI id = those traits" | |
| 19:42:59 | bauzas | the either | |
| 19:44:44 | mriedem | artom: i just know that request id gets logged automagically | |
| 19:44:59 | mriedem | and periodic tasks can bleed to use the in-memory user request context which makes logging confusing at times | |
| 19:45:31 | mriedem | artom: see https://review.openstack.org/#/c/524306/2 | |
| 19:45:54 | artom | mriedem, OK, thanks :) | |
| 19:53:14 | openstackgerrit | Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704 | |
| 19:53:34 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 19:53:35 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 19:53:36 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 19:53:37 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 19:53:38 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 19:53:39 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 19:53:40 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 19:53:41 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 19:53:42 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 19:58:37 | mnaser | mriedem, dansmith: sorry for bugging you but i just wanna get this right.. https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L96 Architecture inherits BaseNovaEnum and if i import BaseNovaEnum inside a seperate module (say, nova.virt.arch) then inheriting/importing that brings me back to the same problem | |
| 19:58:55 | dansmith | mnaser: don't move the field, | |
| 19:58:58 | dansmith | just move ALL | |
| 19:59:51 | openstackgerrit | Eric Fried proposed openstack/nova master: __str__ methods for RequestGroup, ResourceRequest https://review.openstack.org/568353 | |
| 19:59:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Granular requests to get_allocation_candidates https://review.openstack.org/515811 | |
| 20:00:18 | mriedem | right just the constant definition | |
| 20:00:32 | openstackgerrit | Chris Dent proposed openstack/nova master: Extract part of PlacementFixture to placement https://review.openstack.org/568359 | |
| 20:00:41 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Refactor _build_device_metadata https://review.openstack.org/533804 | |
| 20:00:42 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Consider hostdev devices when building metadata https://review.openstack.org/533805 | |
| 20:00:59 | openstackgerrit | Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704 | |
| 20:01:06 | mnaser | dansmith: ooo. so .. from nova.virt.arch import <something>, class Architecture(BaseNovaEnum): <insert all existing definition>, ALL = <something> ? | |
| 20:01:29 | dansmith | mnaser: from nova.virt import arch | |
| 20:01:45 | dansmith | mnaser: class Architecture(NovaBaseEnum): ALL = arch.ALL | |
| 20:02:01 | mnaser | ooo okay, and should i rename the other arches to be something like.. MIPS = arch.MIPS so they arent defined twice? | |
| 20:02:10 | mnaser | without breaking any old dependency on those | |
| 20:02:15 | dansmith | mnaser: I don't think you need to do that, do you? | |
| 20:02:27 | mnaser | i don't, but then i'd have all the architectures defined twice? | |
| 20:02:37 | dansmith | anyone that references nova.objects.fields.Architecture.MIPS should change to arch.MIPS | |
| 20:02:39 | lyarwood | mriedem: finally back online, thanks for chasing down the LM failure! | |
| 20:02:45 | mnaser | oooh okay | |
| 20:02:52 | mnaser | so change the references rather than copy pasta | |
| 20:02:57 | mnaser | okay, i follow now | |
| 20:02:58 | mnaser | it makes sense | |
| 20:03:00 | mriedem | lyarwood: np, just working on backports now | |
| 20:03:09 | dansmith | mnaser: ugh, well, there are a ton unfortunately | |
| 20:03:41 | efried | mnaser, dansmith: Why not a local import? | |
| 20:03:42 | mnaser | yeah, mostly in tests | |
| 20:03:47 | dansmith | 344 | |
| 20:03:47 | dansmith | mnaser: % grep fields.Architecture -r nova | wc -l | |
| 20:04:04 | mnaser | but still a but of nova/virt changes | |
| 20:04:08 | dansmith | mnaser: so I guess just do MIPS = arch.MIPS for all of those for your backportable change | |
| 20:04:29 | bauzas | jaypipes: /me goes offline, but lemme know if you want to see the above point about having a conf opt like "this PCI ID = those traits" added in https://review.openstack.org/#/c/557065/ | |
| 20:04:31 | mnaser | i'll do that and then i'll do a follow up cleanup which can sit in master and create a merge conflict for everyone's code :) | |
| 20:04:34 | mnaser | (sorry in advance) | |
| 20:04:55 | dansmith | mnaser: yeah :) | |
| 20:06:11 | mnaser | but actually what do you mean by a local import efried ? can we import things inside a class? | |
| 20:06:50 | mnaser | kinda like `import nova.virt.arch.*` inside Architecture? | |
| 20:06:52 | mriedem | the conf option is global module level so i'm not sure you can do a local import there | |