| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-10 | |||
| 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 | |
| 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 | |
| 01:40:44 | Kevin_Zheng | I have to rebase anyway | |
| 01:41:05 | mriedem | the 2.24 api sample test is posting the live migration and deleting it with 2.24 but using the 2.1 sample | |
| 01:41:22 | mriedem | because the actual request didn't change between then it works | |
| 01:42:45 | Kevin_Zheng | Ah, I got it | |
| 01:42:59 | Kevin_Zheng | if we inherent 2.24 | |
| 01:43:09 | Kevin_Zheng | it was setup first | |
| 01:43:26 | Kevin_Zheng | and then again self.api.microversion was assigned to be 2.25 | |
| 01:43:28 | Kevin_Zheng | 2.24 | |
| 01:44:12 | Kevin_Zheng | because self.api.microversion=2.24 is after super.setup() | |
| 01:45:36 | Kevin_Zheng | and since it is wrpped in setUp, I can do nothing | |
| 01:46:25 | mriedem | yup | |
| 01:47:45 | Kevin_Zheng | yeah, I'm still young, I can remember things | |
| 01:48:18 | mriedem | what were we talking about again? | |
| 01:48:47 | Kevin_Zheng | I cant remember | |