Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-14
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
20:03:47 dansmith 344
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
20:07:06 efried mnaser: It probably won't work for what you're doing here, because it's the import of fields from within the conf setup that's blowing you up.
20:07:07 mriedem oh right that
20:07:18 efried yeah, what mriedem said.
20:07:30 mnaser figured i'd ask anyways :)
20:08:15 efried mnaser: Yes, you can do imports from within a class method. But doing it within a class (outside of a method) won't really help you, because that'll be processed when the file is read rather than at runtime, which is what you would need.
20:14:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: libvirt: Report the virtual size of RAW disks https://review.openstack.org/568363
20:20:19 openstackgerrit Chris Dent proposed openstack/nova master: Extract part of PlacementFixture to placement https://review.openstack.org/568359
20:30:40 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: libvirt: Report the virtual size of RAW disks https://review.openstack.org/568369
20:40:14 dansmith mriedem: hmm, gate reset?
20:41:29 dansmith ugh yep
20:41:51 dansmith mriedem: was going to try to be all good and go hit your backports right after the master one merged, but.. :/

Earlier   Later