Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-30
16:38:30 stephenfin AJaeger: I kid. +2
16:38:45 AJaeger stephenfin: ;9
16:40:03 mriedem nope still fails
16:40:06 mriedem host2 shows up in cell1
16:41:21 melwitt sad town :(
16:41:46 mriedem looking at CellDatabasesTestCase i'm not sure why this doesn't work
16:41:50 mriedem except,
16:42:02 mriedem when the compute node record is created, it's via the start of the service,
16:42:07 mriedem which has an untargeted context,
16:42:16 mriedem so it's going to create the service/computenode in the default context, which is cell1
16:42:18 mriedem so i guess that's why
16:42:46 mriedem to hack around this, i'd have to create the compute node records in the cells before actually starting the services
16:43:00 mriedem or allow temporarily mutating the default context in the CellDatabase fixture
16:43:21 openstackgerrit Eric Fried proposed openstack/nova master: Nix log translations from scheduler.client.report https://review.openstack.org/524245
16:43:27 melwitt well, what I did in my patch is wrap the Service class and target the context during start
16:44:02 melwitt if that's not working then I messed up what I tried to do
16:46:17 kashyap dansmith: When you get a moment, maybe you'd know top off your head -- during 'evacuate', certainly CPU model compatibility is checked before an instance is moved away, yes?
16:46:45 dansmith kashyap: if we run the scheduler then I assume so
16:46:45 mriedem kashyap: would depend on the scheduler filters
16:46:56 mriedem unless, of course, you specify a host with the force option
16:46:56 dansmith if a host is provided, I don't think so
16:47:02 mriedem then we bypass the scheduler altogether
16:47:14 mriedem it's not the same
16:47:16 mriedem evacuate is a move
16:47:16 kashyap mriedem: Yep, scheduler filters is what I was going toc heck
16:47:17 mriedem rebuild is not
16:47:42 mriedem you can evacuate with a target host and if you don't specify the force flag, we'll validate that host against the scheduler filters,
16:47:50 mriedem if you specify a host + force, we don't run through the scheduler filters
16:47:59 mriedem because you've decided you want to shoot yourself in the foot
16:48:04 mriedem and we hand you the gun to do that
16:48:47 kashyap dansmith: mriedem: Do you have a pointer to the relevant Scheduler code? libvirt / QEMU has reworked how CPU models are detected, so I'm trying to investigate what action items are there on the Nova side
16:48:55 mriedem if you rebuild (not evacuate) with a new image, well, then it depends on which roll of the cve dice you've landed on
16:48:55 kashyap mriedem: Heh, noted
16:49:15 mriedem kashyap: the compute capabilities filter
16:49:30 mriedem https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py
16:49:44 mriedem i think anyway
16:49:53 mriedem i'm not super well versed in the details of what all the filters do
16:49:58 mriedem bauzas would know
16:50:13 kashyap Wauw, thanks for the super quick response
16:50:35 kashyap dansmith: Yes, good point on the "if you provide a host, then no checks are performed"
16:50:56 kashyap Because, well, if you're providing a target host yourself, then you're expected to keep an eye on CPU comapt
16:51:03 kashyap s/comapt/compat/
16:55:43 kashyap mriedem: I think the scenario where one would "specify a host + force" is the admin damn sure knows about his target host, and wants to avoid extra checks?
16:56:21 mriedem wants to avoid the scheduler kicking out the specified host, yes
16:56:25 edleafe kashyap: yes, that was the idea
16:56:34 edleafe "I'm the admin, dammit!"
16:56:38 mriedem i.e. i know this instance doesn't fit on this host, but i'm going to shove it in there anyway
16:56:41 kashyap edleafe: Thanks, noted.
16:57:20 kashyap bauzas: When you're about, I don't see CPU-compat related checks in the 'compute_capabilities_filter.py' -- https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py
16:57:45 mriedem kashyap: that's because the filter is generic
16:58:03 mriedem stats = getattr(host_state, 'stats', {})
16:58:12 mriedem that stats stuff is put on the compute node down in the resource tracker / claim code
16:58:45 mriedem https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L561
17:00:10 mriedem the cpu stats comes off the driver here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7380
17:00:35 kashyap Yeah, that I have open
17:00:36 mriedem although that might be a different thing,
17:00:40 mriedem for the cpu monitor stuff
17:00:43 kashyap Thanks for the precise pointers
17:01:06 kashyap mriedem: Aside, do you know top off your head, where is the Git repo for this file? -- https://docs.openstack.org/nova/pike/configuration/config.html)
17:01:32 mriedem nova
17:01:45 mriedem https://docs.openstack.org/nova/pike/configuration/sample-config.html
17:04:02 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Genericify the instance_list stuff https://review.openstack.org/524253
17:04:03 dansmith mriedem: see if you don't not hate this ^
17:04:19 kashyap mriedem: Thanks. (So, it's this - ./doc/source/configuration/sample-config.rst)
17:04:24 dansmith mriedem: seems to work and be fairly straightforward actually
17:04:36 dansmith mriedem: I need to do a lot of cleanup and fixing the docs of course
17:04:50 dansmith but if you like that I will do that post haste and then we can ask the migration dudes to base on that
17:05:51 dansmith mriedem: look at the InstanceLister class for the things you have to implement in order to be cross-cell-listable
17:08:27 mriedem dansmith: i like it
17:08:41 mriedem yeah it delegates the db / object calls to the subclass impl
17:08:42 mriedem which is nice
17:08:44 dansmith right
17:08:49 mriedem only suggestion was using an abc at the top
17:08:51 dansmith might even be easier to digest if you're looking at it cold
17:08:57 dansmith I KNEW you were going to say that
17:09:08 dansmith almost put a comment like "Yes matt, I know"
17:09:34 mriedem that would be a fun easter egg
17:10:30 mriedem kashyap: looking at the libvirt driver i don't see that it returns 'stats' from get_available_resources
17:10:43 mriedem so i'm not really sure how that would work with the compute caps filter
17:10:58 kashyap Hmm
17:12:09 mriedem might be the cpu_info or supported_instances fields
17:12:20 mriedem those get put on the compute node record, which is the HostState object (wrapper) in the scheduler filter
17:12:35 mriedem no https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7380 is for the cpu monitor metric stuff i think
17:12:38 mriedem which is a weigher
17:12:40 mriedem i think
17:12:52 mriedem i think you're looking for the cpu_info field on the compute node
17:13:03 mriedem https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5826
17:14:51 kashyap Thanks for clarifying; I think that looks like it.
17:15:34 kashyap mriedem: dansmith: Speaking of Easter eggs, try this one -- https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030
17:15:37 kashyap :-)
17:15:55 kashyap It actually broke a _real_ use-case
17:16:26 kashyap But the 'man' authors were graceful enough to immediately admit that it wasn't supposed to affect error-scenarios, and fixed it right away.
17:16:40 kashyap (While still retaining the easter egg.)
17:17:23 kashyap (However, no one complained about that bug for _6_ years. So, it's edge case.)
17:18:16 openstackgerrit Merged openstack/nova master: check query param for server groups function https://review.openstack.org/500347
17:29:09 openstackgerrit Ildiko Vancsa proposed openstack/nova master: libvirt: Allow multiple volume attachments https://review.openstack.org/267587
17:29:09 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
17:31:40 cfriesen melwitt: (or anyone else) has bug 1469179 been fixed with placement/resource_providers?
17:31:41 openstack bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] https://launchpad.net/bugs/1469179 - Assigned to melanie witt (melwitt)
17:34:10 melwitt cfriesen: not yet. at the ptg when we discussed placement priorities, other items were more pressing, like alternate hosts and nested resource providers. so shared storage got bumped to rocky

Earlier   Later