| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-10 | |||
| 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 | |
| 00:51:22 | gmann | if you guys have not started that yet | |
| 00:53:41 | openstackgerrit | Merged openstack/nova master: update project/user for consumer in allocation https://review.openstack.org/581139 | |
| 01:02:29 | mriedem | gmann: no one has started an etherpad yet | |
| 01:03:04 | gmann | mriedem: ok. | |
| 01:05:57 | Kevin_Zheng | mriedem Hi, thanks for the review on my patch, I have one question and I left a comment on yikun's patch yesterday, | |
| 01:06:09 | mriedem | ok | |
| 01:06:31 | Kevin_Zheng | on what scenario should I bump compute version to 5.1 and what scenario to 5.0? | |
| 01:06:58 | Kevin_Zheng | like the last 3 bump was still 5.0 but added 3 versions | |
| 01:07:08 | mriedem | those were for behavioral changes | |
| 01:07:16 | mriedem | the rpc api version itself changes if the rpc api changes | |
| 01:07:23 | mriedem | like adding/changing parameters in an rpc api method | |
| 01:07:29 | mriedem | like you did in live_migration_abort | |
| 01:07:56 | Kevin_Zheng | OK, I got it, that also what I thought | |
| 01:07:56 | mriedem | e.g. # Version 31: The compute manager checks if 'trusted_certs' are supported | |
| 01:08:13 | mriedem | there is a version check for minimum nova-compute >= 31 if trying to create a server with trusted_certs | |