| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-14 | |||
| 19:20:25 | mnaser | dansmith, mriedem: ideally i'd like to have this to be backportable to queens at least... because it prevents us from multiarch.. how about i do a patch without choices= and then follow up that moves stuff to virt/arch then adding the choices in a third patch, allowing us to have 1 backportable patch that doesnt break the world? | |
| 19:20:37 | mnaser | dansmith: but i have to be in the top 10 in stackalytics to get my bonus | |
| 19:20:58 | dansmith | mnaser: I'd rather it be one patch than go in (and especially be backported) without choices= | |
| 19:21:25 | mnaser | (i honestly had a candidate that said they couldn't change their email because "their marketing department at old company" needed to show off cores upstream) | |
| 19:21:29 | dansmith | if you have a config you backport that has no restrictions and then introduce a restriction, you broke compat | |
| 19:21:55 | mnaser | as you can imagine that was eye opening.. | |
| 19:22:29 | mnaser | dansmith: ok i see, i guess i'll throw the dice and hope for mercy by the stable maint gods | |
| 19:23:01 | dansmith | mnaser: mriedem is a stable maint god | |
| 19:23:09 | dansmith | and I'm a stable maint peasant | |
| 19:23:23 | dansmith | so do whatever he says, but I think he'll be on the same page :) | |
| 19:24:13 | bauzas | jaypipes: around ? | |
| 19:25:02 | bauzas | jaypipes: about https://review.openstack.org/#/c/557065/ | |
| 19:25:07 | bauzas | good question ^ | |
| 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: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 | mriedem | which causes all sorts of confusion wrt the request id | |
| 19:39:42 | bauzas | jaypipes: so, the question you have is more about how nova could use standard traits, then | |
| 19:39:47 | jaypipes | bauzas: why would they do that, though? | |
| 19:40:00 | bauzas | jaypipes: why what ? using custom traits ? | |
| 19:40:00 | mriedem | artom: https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L40 | |
| 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 | artom | mriedem, so there's a global context per thread? | |
| 19:40:56 | bauzas | jaypipes: I don't disagree with that :) | |
| 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 | mnaser: % grep fields.Architecture -r nova | wc -l | |