Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-07
19:22:07 mriedem so,
19:22:26 mriedem if we move the claim/allocation stuff to the scheduler, can we still do this data migration sync up on nova-compute start?
19:22:53 mriedem i mean, we can, we have the scheduler report client,
19:23:02 mriedem and the update_available_resource periodic,
19:23:07 mriedem just wondering if that will handle it
19:23:15 superdan mriedem: the compute node also isn't going to report any GOLD resources available until it starts up on new code either
19:23:32 superdan so I think if you restart onto the new scheduler,
19:24:17 superdan we'll start asking for resources that expose GOLD once the flavors are updated, but no computes will have any GOLDs to give until they are restarted and start exposing that
19:24:17 superdan wait
19:24:23 superdan did we already do that part in ocata?
19:24:26 superdan yeah, okay yeah
19:24:31 superdan I think I've got this now
19:24:35 superdan lemme try again:
19:24:57 superdan In ocata, we got the ironic driver to expose 1 $ironic_node_resource_class for each node to placement
19:25:10 superdan if we update the real flavors with the new resource type,
19:25:14 openstackgerrit melanie witt proposed openstack/nova master: Make security_group_rules use check_deltas() for quota https://review.openstack.org/477700
19:25:16 openstackgerrit melanie witt proposed openstack/nova master: Remove 'reserved' count from used limits https://review.openstack.org/446242
19:25:17 openstackgerrit melanie witt proposed openstack/nova master: Make key_pairs use check_deltas() for quota https://review.openstack.org/477699
19:25:20 openstackgerrit melanie witt proposed openstack/nova master: Remove useless quota_usage_refresh from nova-manage https://review.openstack.org/446243
19:25:21 openstackgerrit melanie witt proposed openstack/nova master: Count instances to check quota https://review.openstack.org/416521
19:25:25 superdan scheduler would send instances to busy computes thinking there was room
19:25:27 openstackgerrit melanie witt proposed openstack/nova master: Make Quotas object favor the API database https://review.openstack.org/410945
19:25:28 superdan what we need,
19:25:34 openstackgerrit melanie witt proposed openstack/nova master: Add online migration to move quotas to API database https://review.openstack.org/410946
19:25:35 openstackgerrit melanie witt proposed openstack/nova master: Limit maximum pending resizes for preventing over quota https://review.openstack.org/481739
19:25:45 superdan is to data migrate the _instance_ flavors to also report that they use one of the new resources,
19:25:59 superdan so that the computes start reporting 1 total, 1 used, 0 available
19:26:13 superdan so really,
19:26:26 superdan ops just need to run data migrations before they update the main flavors to use the override I think
19:26:31 superdan make sense/
19:27:31 mriedem yeah, that's where i was going in my head,
19:27:53 mriedem that the compute updates the existing instance embedded flavor on startup so we can fix the allocations reported in,
19:28:02 superdan right
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 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:25 superdan mriedem: that part is done already
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,

Earlier   Later