Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-07
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
21:01:37 mriedem and https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-claims.html#work-items
21:01:44 mriedem "Make compute nodes GET /allocations/<instance_id> for verifying if already created, and if so, don’t POST allocations to Placement service."
21:01:50 mriedem that's what i'm thinking of
21:02:02 mriedem we can sort it out on monday when everyone is actually around
21:02:07 mriedem including his bauzasness
21:02:30 superdan https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L859-L877
21:02:52 superdan L868 stops if they're equal
21:03:01 mriedem yeah i know about that,
21:03:39 superdan bypassing the existing RT still needs to happen
21:03:44 mriedem but we're still doing all of this other claim checking stuff in the compute that seems unnecessary - although there are going to be things the compute side claim will pick up that we don't in the scheduler, like pci/numa and overhead
21:03:50 superdan yep
21:04:07 mriedem i wasn't sure what we were going to do about the nfv resources
21:04:27 mriedem and i thought in boston for overhead we said, well, you adjust the reserved amount configs to buffer your inventory
21:04:54 superdan we said we'd do the simple thing first, expecting the op to reserve enough,
21:05:02 superdan potentially updating reserved automatically after that yeah
21:06:40 mriedem i'll just go back to my corner with https://review.openstack.org/#/c/471899/ where things make sense
21:30:37 Apoorva Our Cinder CI is failing with following error http://paste.openstack.org/show/614811/. Is this a known issue?
21:44:21 sgordon so i am looking at this thread http://lists.openstack.org/pipermail/openstack/2017-July/thread.html#45139
21:44:31 sgordon "[Openstack] Live Migration and LibVirt CPU Mode"
21:44:52 sgordon and i could swear there was a legit bug around this at some point but am struggling to pin down where it was discussed/fixed
21:45:46 sgordon specifically "Therefore it appears if a VM XML CPU definition contains "cpu mode='host-model'" the cpu model is ignored and the 2 host CPU models are compared."
21:45:51 openstackgerrit Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322
21:50:48 sgordon ring any bells for anyone?
21:51:58 superdan sgordon: I think maybe kashyap was discussing that with someone at some point?
21:53:02 sgordon superdan, yeah - it definitely sounds familiar i just cant remember the outcome
21:53:18 superdan yeah that's about all I know
21:56:24 cburgess superdan sgordon That sounds about right. What is the specific question?
21:58:47 cburgess if so then... working as intended.
21:58:53 sgordon yeah but host model is not really host model
21:59:02 sgordon it's an approximation of the host model
21:59:09 cburgess Right
21:59:44 sgordon if you go downthread i think they are saying they get the same when using custom and specifying westmere
22:00:00 cburgess Let me keep reading...
22:02:10 cburgess I wonder if he has different versions of libvirt/kvm between the hosts.
22:02:35 sgordon possibly
22:02:43 cburgess "I'm beginning to suspect that because the VM has "cpu mode='host-model'" in its xml CPU definition,"
22:02:44 sgordon there is not much/any info about what versions of anything are in use
22:02:48 cburgess As I said.. working as intended.

Earlier   Later