Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-10
20:29:54 mriedem see my comment
20:30:28 mriedem i think the scenario is you are attempting to abort a queued live migration but the compute is old
20:30:49 dansmith yeah I see it, but.. this code runs in the api itself, and doesn't actually know the version of the compute it's going to talk to
20:30:52 mriedem his check for 'compute too old' is the can_send_version
20:31:06 dansmith that's not compute-aware
20:31:58 mriedem so his version check on the nova-compute service needs to happen in the api change if the user is trying to abort a !running migration and the host is old
20:32:02 mriedem s/host/service/
20:32:09 dansmith can_send_version() is looking at the api service's rpc pin, which might be computed from service version, or manually set
20:32:23 dansmith mriedem: right
20:32:28 mriedem ok, he's just following similar checks in compute rpc api for things like tagged attachments and such
20:32:49 dansmith mriedem: and by the time we get to rpcapi, we don't have any new information we didn't have a couple frames up on the stack, so no need to do it again
20:32:57 openstackgerrit Matt Rabe proposed openstack/nova master: Add destination MSP IP address to PowerVM migrate data https://review.openstack.org/581463
20:33:07 dansmith yeah, those are for things that haven't already checked service version for the actual compute and are relying on the pin I think
20:33:20 dansmith which is a way to do it, but you don't need to do it in both places
20:33:58 mriedem so if we check the nova-compute service version, we don't need the can_send_version (or any) changes to the compute rpcapi at all right?
20:34:08 dansmith well, no,
20:34:09 openstackgerrit Chris Dent proposed openstack/nova master: Remove unused variable in migration https://review.openstack.org/581464
20:34:16 dansmith which is why I was saying earlier
20:34:52 dansmith you can check the service version to know whether all computes or the compute supports the !running cancel, but you don't know if the rpc pin is manually set low,
20:34:53 dansmith so you need to do the can_send_version check in rpcapi
20:35:09 openstackgerrit Matt Rabe proposed openstack/nova master: Add destination MSP IP address to PowerVM migrate data https://review.openstack.org/579676
20:35:19 dansmith which might be a reason to just do it there only, and not also up in api and just catch the exception
20:35:50 dansmith let rpcapi tell you if the thing you're asking for is doable right now, and if not tell the user they can't have it
20:35:55 dansmith since rpcapi can check both things
20:36:11 dansmith don't need to check the service version itself for this I don't think
20:36:16 mriedem yeah ok - i was wondering why he didn't just *move* the status check to rpcapi instead of duplicate it
20:36:20 dansmith yeah
20:36:30 mriedem you want to leave a comment in that change?
20:36:38 dansmith not really, but I will :P
20:36:42 mriedem thanks
20:55:31 mriedem this is weird https://github.com/openstack/nova/blob/8469fa70dafa83cb068538679100bede7679edc3/nova/objects/service.py#L323
20:57:42 cdent mriedem: that is odd
20:58:09 mriedem https://review.openstack.org/#/c/161822/5/nova/objects/service.py
20:58:20 openstackgerrit Rick Bartra proposed openstack/nova master: Add granularity to os-services API https://review.openstack.org/578553
20:59:13 mriedem i have no idea why that was added there,
20:59:17 mriedem but lots of people were approving of the chnage
20:59:19 mriedem *change
20:59:51 mriedem aha https://review.openstack.org/#/c/161822/2/nova/db/sqlalchemy/api.py@425
20:59:57 mriedem the db api used to behave that way
21:00:04 mriedem so it was mirrored in the object
21:01:13 openstackgerrit Eric Fried proposed openstack/nova master: Tighten up ReportClient use of generation https://review.openstack.org/556669
21:01:27 mriedem apparently the service startup code relies on that to determine if it needs to create the service record
21:01:30 mriedem rather than just handling the notfound
21:11:05 openstackgerrit Eric Fried proposed openstack/nova master: Check provider generation and retry on conflict https://review.openstack.org/556669
21:37:23 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Avoid BadRequest error log on volume attachment https://review.openstack.org/581453
21:45:51 mriedem dansmith: question in the numa aware vswitch hardware change here https://review.openstack.org/#/c/564448/14/nova/tests/unit/virt/test_hardware.py@3343
21:46:42 dansmith mriedem: see my comment on that in an earlier PS?
21:46:55 mriedem nope
21:47:05 dansmith mriedem: I think the deal is, the physnet may be available on the host, but the operator hasn't said that it's particularly affined to some node
21:47:21 dansmith I stumbled on that as well, but worked out the reasoning from the comments and the tests
21:48:06 mriedem but the point is,
21:48:18 dansmith I dunno if that would just be "the operator doesn't care enough to configure the thing" or if there's some reason why it may not be affined, like it's too dynamic or something
21:48:28 mriedem as a user i can say i want to be affined to baz and if the operator hasn't reported baz, we'll still do the build even though you might not be affined to baz
21:48:47 mriedem i'm thinking of it like inventory - is that the wrong way to think about this?
21:48:56 dansmith no, that comment says that the user has requested network baz, and the compute node will do it,
21:49:02 mriedem i see stephenfin has also dropped the patch that does any RT claims code
21:49:05 dansmith but there is no *numa* affinity between a numa node and network baz
21:49:36 mriedem 'compute node will do it' as in, wire up the ports on network baz
21:49:40 dansmith yeah
21:49:48 dansmith the user doesn't request numa affinity to a network,
21:50:30 dansmith they request some network, and maybe some numa layout, but this process makes sure we select a favorable numa pinning of guest nodes to host nodes such that they won't end up on no affined nodes to the network they want
21:51:17 mriedem assuming the operator has exposed that affinity info on the host...
21:51:18 mriedem yeah?
21:51:55 dansmith has configured it, yeah
21:52:11 dansmith the user doesn't really know anything about this behind the scenes optimization
21:52:20 dansmith they may know that their network performance isn't what it should be,
21:52:32 dansmith but they ask for high-level things like being connected to network baz,
21:52:46 dansmith and expect the backend is configuring their numa layout and pinning properly
21:52:49 dansmith right now that doesn't happen,
21:53:04 dansmith and if an operator doesn't or can't configure that information, they'll get what they get today
21:53:45 mriedem can they, or can't they, throw a fit when they don't like what they get
21:53:56 mriedem ignore that
21:54:49 mriedem ok that helps anyway, i was approaching this whole bp as a pass/fail type thing (hence the inventory thinking) rather than an optimization
21:55:14 dansmith well, the hardware fitting thing is pass/fail
21:55:16 dansmith meaning,
21:55:24 dansmith "these nodes pass/fail my test for good-enough"
21:55:31 mriedem so if i want baz and only foo and bar are reported, i get whatever. but if i want foo and foo is reported somewhere, scheduler picks that one specifically.
21:55:35 mriedem right
21:55:36 dansmith but in the case of no information, they pass as they do today
21:55:44 dansmith yeah
21:55:58 mriedem ok yeah - i should have read the tests when reviewing the code earlier
21:57:49 mriedem ok +2 up through that point as well
21:59:07 dansmith okay, I won't get back to that today but I'll plan on it first thing in the morning
21:59:24 dansmith and then circle back on yikun's assuming he gets it re-worked overnight
22:01:05 mriedem i'm sure his first and most pleasurable thing to do in the morning is figure out wtf we've done to his code series :)
22:03:45 dansmith hah yeah
22:22:58 mriedem stephenfin: why was the numa-affined vswitch RT claims change dropped? https://review.openstack.org/#/c/564449/3/nova/compute/claims.py
22:23:13 mriedem we can still have a late race/collision during the claim on the compute can't we?
22:41:25 openstackgerrit Merged openstack/nova master: hardware: fix hugepages memory usage per intances https://review.openstack.org/580657
22:59:12 openstackgerrit Merged openstack/nova master: Update root providers in same tree https://review.openstack.org/580246
22:59:22 openstackgerrit Merged openstack/nova master: Use nova.db.api directly https://review.openstack.org/543262
22:59:36 openstackgerrit Merged openstack/nova master: Refactor policies to policy in InstanceGroup DB model https://review.openstack.org/579113
23:31:11 openstackgerrit Merged openstack/os-vif master: doc: Fix formatting issues https://review.openstack.org/580443
#openstack-nova - 2018-07-11
00:23:02 openstackgerrit Takashi NATSUME proposed openstack/nova master: Transform metrics.update notification https://review.openstack.org/580567
00:24:04 openstackgerrit Merged openstack/os-vif master: Remove unnecessary pyNN testenv sections https://review.openstack.org/577686
00:30:29 openstackgerrit Merged openstack/os-vif master: Remove [tox:jenkins] section from tox.ini https://review.openstack.org/580886
00:48:14 gmann mriedem: alex_xu yeah, those are being ignored as per additionalProporties=True
00:49:15 gmann mriedem: alex_xu same legacy issue we had to keep about --all-tenant which i tired to fix but its more UX tradeoff and where we should fix in APi or on client side - https://review.openstack.org/#/c/198184/
00:50:08 gmann mriedem: alex_xu how about doing additionalProperties=False with microversion in stein so that user can get clear 400 instead of confusing ignore things.
00:50:55 gmann and we can include more API fixes in that as mriedem said. i can start a etherpad for that and then we choose appropriate issues to fix in single version bump

Earlier   Later