| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-10 | |||
| 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 | mriedem | e.g. # Version 31: The compute manager checks if 'trusted_certs' are supported | |
| 01:07:56 | Kevin_Zheng | OK, I got it, that also what I thought | |
| 01:08:13 | mriedem | there is a version check for minimum nova-compute >= 31 if trying to create a server with trusted_certs | |
| 01:08:33 | Kevin_Zheng | ok, so it checks for 31 instead of 5.0 | |
| 01:08:54 | mriedem | yeah because 5.0 doesn't really tell us if trusted_certs is supported in the compute or not | |
| 01:09:04 | Kevin_Zheng | got it | |
| 01:09:34 | Kevin_Zheng | I think I will reply other comments in the patch :) | |
| 01:09:35 | mriedem | similar to yikun's late affinity check policy change | |
| 01:09:43 | mriedem | it's a behavior change in how we check late affinity on the compute | |
| 01:09:48 | mriedem | not an actual interface change in the rpc api | |
| 01:28:19 | Kevin_Zheng | mriedem replied on https://review.openstack.org/#/c/573136/ about why 2.24 sample files were added | |
| 01:29:07 | Kevin_Zheng | I will try to be more clear about this, tring to remember all the details, has been a long time :) | |
| 01:33:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update some placement docs to reflect modern times https://review.openstack.org/581151 | |
| 01:34:18 | openstackgerrit | Merged openstack/nova master: unquiesce instance after quiesce failure https://review.openstack.org/550865 | |
| 01:34:47 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Use hard coded values in schema than reference https://review.openstack.org/581288 | |
| 01:34:49 | mriedem | Kevin_Zheng: i saw the inheritance but i still don't really understand it | |
| 01:36:32 | Kevin_Zheng | mriedem, yeah, I'm trying to remember it but forgot some of the details. | |
| 01:37:08 | mriedem | i see that we don't have any api samples for ServerMigrationsSampleJsonTestV2_24 | |
| 01:37:58 | Kevin_Zheng | yeah, because it dont have microversion | |
| 01:38:03 | mriedem | i think it's the _read_template method | |
| 01:38:23 | mriedem | Kevin_Zheng: can you fix that separately? | |
| 01:38:38 | Kevin_Zheng | it has api.microversion and read_template uses self.microversion | |
| 01:38:49 | mriedem | fix the 2.24 api samples tests in a separate change before your new microversion | |
| 01:39:03 | mriedem | hell push that up outside of the series now and i'll approve it | |
| 01:39:06 | Kevin_Zheng | I don't know, because it was correct before my adding | |
| 01:39:14 | Kevin_Zheng | OK | |
| 01:39:40 | Kevin_Zheng | I still want to tell you the root cause though :) | |
| 01:39:49 | mriedem | i see the root issue, | |
| 01:39:52 | Kevin_Zheng | it is something in the setup | |
| 01:39:57 | mriedem | yeah i see that | |
| 01:40:01 | mriedem | ServerMigrationsSamplesJsonTestV2_23 is doing it correctly | |
| 01:40:37 | Kevin_Zheng | OK then I will make it a seperate patch | |