Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-07
19:28:04 mriedem and it's good that none of it turns on until you fiddle the flavors
19:28:11 superdan yeah
19:28:49 mriedem although, we don't actually pull the custom resource off the instance.flavor in the compute, we pull it off the node
19:29:02 mriedem so i'm a bit fuzzy on where the existing instance.flavor comes into play
19:29:40 mriedem this https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L658
19:29:44 superdan we report inventory based on the node
19:29:50 superdan we report allocations based on the instance/flavor
19:30:00 superdan and we request from placement based on the real flavor
19:30:55 mriedem ok so RT updates allocations here https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1012
19:31:52 mriedem and this is where we get the allocations off the instance right? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L141
19:32:02 mriedem which is only ram, cpu and disk
19:32:06 mriedem not fancy pants ironic stuff
19:32:18 superdan yeah
19:32:40 superdan we kinda need the ironic driver to do the instance flavor migration though I think
19:32:58 mriedem sure, but there are 2 parts to this if i'm understanding,
19:33:00 superdan because it'd be hard to do that from nova-manage, not being 100% sure the hypervisor type of an instance I think
19:33:15 mriedem 1. ironic driver updates the instance.flavor if it doesn't have the custome rresource class but the node.resource_class is set
19:33:38 mriedem 2. scheduler report client needs to account for custom resource class allocations off the instance flavor
19:33:54 mriedem then 3. deployer fiddles the bits
19:33:58 mriedem 4. cleanup
19:34:40 mriedem i think #2 is missing from the spec, unless i'm missing something
19:34:51 superdan yeah I suppose you're right
19:34:55 superdan it's implied
19:35:00 mriedem heh
19:35:16 mriedem mayhap i'll update the spec quick
19:38:43 melwitt superdan: can you tell where I would need to put an "objects.register_all()" to call object classmethods in the websocketproxy? would it have to be here or is there a way it could only be done once? https://github.com/openstack/nova/blob/master/nova/console/websocketproxy.py#L71
19:39:41 superdan melwitt: you could do it at module-level.. it is only needed once per process
19:40:07 melwitt superdan: okay, cool. thanks
19:40:12 superdan you wouldn't want to do it per-request like that
19:41:02 melwitt yeah, that's what I was thinking
19:42:45 openstackgerrit melanie witt proposed openstack/nova master: Convert websocketproxy to use db for token validation https://review.openstack.org/333990
19:55:04 mriedem superdan: oh i guess that allocations thing was mentioned in the deps section https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html#dependencies
19:55:25 superdan mriedem: that part is done already
19:55:25 mriedem maybe that was supposed to or expected to happen in http://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/custom-resource-classes.html
19:55:41 mriedem "This depends on work to change the resource tracker to allow drivers to expose allocations of custom resource classes"
19:55:43 superdan the migration of existing instances is different from what is described there, and is specific to ironic
19:55:51 superdan right that depends-on is done
19:55:56 mriedem we don't expose allocations for custom resource classes
19:56:04 mriedem we expose inventory for custom resource classess
19:56:05 superdan we can from the driver, hang on
19:56:14 superdan oh
19:56:20 mriedem that's what i was talking about in https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L141
19:56:28 superdan yeah okay
19:56:36 superdan I was glossing over the allocation word there
19:57:25 superdan there's still the migration work that needs doing which is neither of these
19:57:56 mriedem yeah i think i've covered that here in this spec update, hold on
19:58:06 superdan cool, I gotsta jump on a call
19:59:13 mriedem geez another one
19:59:18 mriedem these aren't 900 numbers are they?
19:59:25 superdan I have a problem
20:11:05 melwitt grr, internet is on the fritz again
20:15:11 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Amend spec for "Allow custom resource classes in flavor extra specs" https://review.openstack.org/481748
20:15:12 mriedem superdan: leakypipes: figleaf: ^
20:15:27 melwitt mriedem: I think that tempest test works because the common.get_instance() method gets the instance via compute/api and that does a set_target_cell() that targets the context to the cell the instance is in
20:15:44 mriedem melwitt: so the same reason that normal attach works
20:15:48 mriedem so even though the instance isn't on a host,
20:15:51 mriedem it's still mapped to the original cell
20:16:02 mriedem tricksy baggins
20:16:09 mriedem melwitt: i told you you were the only one that could figure it out
20:16:28 mriedem ha
20:17:58 mriedem mayhap you'd like to +W https://review.openstack.org/#/c/481683/
20:18:40 mriedem actually,
20:18:44 mriedem so maybe this means we don't need that fix
20:19:30 mriedem yeah, it was'nt failing b/c the context is already targeted
20:19:54 melwitt mriedem: yeah I was wondering, what broke that brought up the bug?
20:20:18 mriedem nothing :(
20:20:27 mriedem i noticed the local creation part during a review of something unrelated,
20:20:36 mriedem and because of how local delete has bit us with cells,
20:20:38 melwitt ah, okay
20:20:48 mriedem i immediately thought this was also busted in a similar way
20:21:32 melwitt yeah, the set_target_cell is so hidden that it's hard to tell when we need an extra target cell or not
20:33:31 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: Fix cropping the endpoint url https://review.openstack.org/479818
20:53:21 superdan mriedem1: ah yeah, so we probably don't need that
20:53:29 superdan mriedem1: hence my asking where/how this came hup
20:53:32 superdan up even
20:55:09 mriedem1 sorry
20:55:26 mriedem the local create thing scared me because of local delete issues
20:55:37 superdan hah
20:55:47 mriedem leakypipes: i went through https://review.openstack.org/#/c/476632/ - we can't actually allocate in the scheduler until we've done the changes in the compute to not claim if the allocations are already done, right?
20:56:02 mriedem otheriwse we allocate in scheduler and still claim in compute
20:56:05 superdan mriedem: we already have that right?
20:56:11 mriedem do we?
20:56:24 superdan mriedem: compute just checks the allocations in placement, changing them only if need be
20:56:35 mriedem but i thought the big win was not doing the claim at all
20:56:38 mriedem in the resourc etracker
20:56:52 superdan we can't drop the RT until this is in place
20:56:56 mriedem plus,
20:57:04 mriedem there should be a minimum compute version check somewhere i thought,
20:57:17 mriedem we had the whole back and forth about sending the actual allocations down to the compute over rpc
20:57:18 superdan mriedem: I dunno, ocata computes did the allocation stuff right?
20:57:21 mriedem to tell the compute if it should claim
20:57:43 superdan that's to tell it if it should forego the normal RT claiming right?
20:57:44 mriedem and i thought we settled on not sending hte allocations claimed over rpc, but instead just have the compute check to see if the allocations were already done for it
20:57:48 mriedem and by pass the claim (noop)
20:58:51 superdan yeah
20:59:16 superdan here's the short and curly of it:
20:59:37 superdan there is BBQ hurling its way towards me at about 60MPH, so I stop caring about this when it gets here
21:00:17 mriedem at 2pm?
21:00:30 superdan hell yes.. taylor gets half day fridays in the summer
21:01:33 mriedem so https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-claims.html#other-deployer-impact

Earlier   Later