| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-11 | |||
| 12:40:38 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree https://review.openstack.org/650878 | |
| 12:40:38 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Query `in_tree` to placement https://review.openstack.org/649535 | |
| 12:40:44 | sean-k-mooney | /query cdent | |
| 12:41:01 | cdent | ? | |
| 12:41:52 | sean-k-mooney | i was going to pm you and had an extra space | |
| 12:41:54 | sean-k-mooney | :) | |
| 12:42:54 | aspiers | lucky you noticed before you said something rude in public ;-) | |
| 13:31:27 | mnaser | is the nova archive tool not hitting cell0 a decision by design? | |
| 13:32:03 | dansmith | mnaser: do you mean archive_deleted_rows? | |
| 13:32:08 | mnaser | yeah | |
| 13:32:23 | dansmith | isn't there an all cells flag for that? | |
| 13:32:33 | mnaser | that was an unmerged patch afaik | |
| 13:32:46 | dansmith | ah, okay, well, then yes by design? :) | |
| 13:32:49 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.openstack.org/649963 | |
| 13:32:53 | dansmith | run it against a config pointing at cell0 | |
| 13:33:02 | mnaser | https://review.openstack.org/#/c/587858/ | |
| 13:33:18 | mnaser | err well | |
| 13:33:20 | mnaser | looks like that was a dup of https://review.openstack.org/#/c/507486/ | |
| 13:33:35 | mnaser | which seems to have stalled out | |
| 13:36:11 | dansmith | mnaser: you can run purge --all-cells --before | |
| 13:36:25 | dansmith | oh wait, | |
| 13:36:33 | dansmith | I was thinking that did an archive first but it does not, nevermind | |
| 13:36:41 | dansmith | it's not like I wrote that... | |
| 13:36:49 | mnaser | it's early :p | |
| 13:36:57 | dansmith | yeah, YEAH. | |
| 13:39:19 | mnaser | anyways, I rechecked that patch and I can iterate here and there to get it to land eventually | |
| 13:39:27 | mnaser | though probably not at a fast pace | |
| 13:54:18 | stephenfin | dansmith, jaypipes, cdent, bauzas: Reworking the cpu-resources spec at the moment. It feels like the general preference is to have a hard break between the current behavior and the new placement-based flow, right? | |
| 13:54:56 | stephenfin | as in only newly deployed compute nodes would support the new behavior | |
| 13:54:57 | bauzas | stephenfin: well, my opinion would be to not have a modification if you have the same options | |
| 13:55:17 | sean-k-mooney | ? | |
| 13:55:32 | bauzas | but maybe however for CONF.vcpu_pin_set | |
| 13:55:36 | cdent | stephenfin: I'd need to load that context back in before being able to say something useful, so will defer to others for now | |
| 13:55:59 | stephenfin | sean-k-mooney: Pretty much this https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@725 | |
| 13:56:36 | bauzas | stephenfin: so, see my opinion : | |
| 13:56:56 | dansmith | stephenfin: no, I think that's the opposite of what we want | |
| 13:56:57 | bauzas | - no modifications for the same options but CONF.vcpu_pin_set | |
| 13:56:58 | sean-k-mooney | well i really wish we did not confalate vCPU with floating | |
| 13:57:12 | sean-k-mooney | or with pinned | |
| 13:57:23 | sean-k-mooney | it has a different meaning then either | |
| 13:58:14 | sean-k-mooney | anyway personally i would like to have two paralle implementions. in train. freeze the current one and implement a paralle placemnt native one and then switch in U or later | |
| 13:58:44 | stephenfin | dansmith: It is? What is the preference? | |
| 13:58:53 | stephenfin | sean-k-mooney: Yeah, that's pretty much where my head was going | |
| 13:59:19 | stephenfin | as for conflating VCPU with floating, I'm not sure what other term we could use | |
| 13:59:51 | sean-k-mooney | a vCPU can be floating or pinned | |
| 13:59:58 | dansmith | stephenfin: I think I said on the review that I was opposed to us solving the problem of accounting by making people move their guests around between computes that are counting the old way and new way | |
| 14:00:18 | dansmith | stephenfin: so having compute nodes never transition to the new way (without being cleaned off first) is not okay | |
| 14:00:20 | mriedem | melwitt: just fyi that i replied to some of your replies in the quotas from placement change https://review.openstack.org/#/c/638073/2 | |
| 14:00:22 | mriedem | https://review.openstack.org/#/c/638073/ | |
| 14:00:25 | sean-k-mooney | i dont like using the vCPU resouce class in plamenet to mean just floating as it has a different menanitn the VCPU in the flavor | |
| 14:00:25 | mriedem | if you're working on updates | |
| 14:01:05 | stephenfin | sean-k-mooney: We're eventually going to kill vcpus in the flavor though | |
| 14:01:09 | sean-k-mooney | dansmith: ok so you are asking for an inpalce reshape or other mechanisuym | |
| 14:01:27 | jaypipes | sean-k-mooney: I think I'm pretty clear in the glossary of that spec. | |
| 14:01:30 | sean-k-mooney | stephenfin: im not really a fan of that but we could | |
| 14:01:55 | sean-k-mooney | jaypipes: yes i know what it say in the spec | |
| 14:02:01 | mriedem | mnaser: dansmith already said this but you can archive cell0 by just running it against a nova.conf with [database]/connection pointed at cell0 | |
| 14:02:07 | jaypipes | sean-k-mooney: that glossary clearly delineates between guest vCPU threads, shared host CPUs (floating CPUs) and dedicated host CPUs (pinned to a guest vCPU thread) | |
| 14:02:20 | stephenfin | sean-k-mooney: Yeah, we won't need it once we're modelling this stuff in placement. That'd be a future work item though | |
| 14:02:39 | stephenfin | sean-k-mooney: and VCPU and PCPU are far more succinct than VCPU_SHARED and VCPU_DEDICATED, even if we're overloading the term vCPU | |
| 14:02:40 | dansmith | stephenfin: we are? (going to kill vcpu in the flavor) ? | |
| 14:03:07 | sean-k-mooney | dansmith: see i dint think we were | |
| 14:03:13 | dansmith | sean-k-mooney: me either :) | |
| 14:03:22 | stephenfin | dansmith: https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@727 | |
| 14:03:23 | mriedem | killing vcpu in the flavor will be a giant change | |
| 14:04:36 | dansmith | stephenfin: you mean adjusting flavor vcpus down to zero for purely physically-pinned instances | |
| 14:04:41 | sean-k-mooney | stephenfin: ya that was one of the parts i disliked about the current spec but i could live with it if we needed too | |
| 14:04:59 | sean-k-mooney | stephenfin: its a faily major api breakage | |
| 14:05:28 | mriedem | is this a known gate breakage and i'm just late to the party? http://logs.openstack.org/50/651650/2/check/openstack-tox-cover/ebe055d/job-output.txt.gz#_2019-04-10_21_35_25_171727 | |
| 14:05:28 | sean-k-mooney | any system the used to inpsect the flaovr vcpu field woudl now have to inspec the resouces dict | |
| 14:05:31 | jaypipes | dansmith: yes. | |
| 14:05:31 | dansmith | maybe we need a hangout | |
| 14:05:32 | mriedem | b'migrate.exceptions.ScriptError: You can only have one Python script per version, but you have: /home/zuul/src/git.openstack.org/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/393_add_instances_hidden.py and /home/zuul/src/git.openstack.org/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/393_placeholder.py' | |
| 14:05:41 | stephenfin | dansmith: Initially, yeah, but at some point that entire field could go. I'm trying to find the place we discussed this in the spec previously (this is a big review) | |
| 14:05:46 | mriedem | oh nvm i need to rebase | |
| 14:05:54 | dansmith | stephenfin: I don't agree with you :) | |
| 14:06:18 | sean-k-mooney | stephenfin: i think it would be better to leave teh vcpu filed in the flavor as the total numaber of cpu and set the vcpu resouce class request to 0 instead in that instance | |
| 14:06:27 | mnaser | wait, why would we kill the cpu field | |
| 14:06:29 | stephenfin | dansmith: Then it's a good thing this isn't actually a stated goal of this particular spec | |
| 14:06:37 | sean-k-mooney | it does not break clients and achive the same goal | |
| 14:06:53 | stephenfin | Let's forget about that and move back to the original question of handling upgrades | |
| 14:07:20 | jaypipes | mnaser: because there's two different actual resource classes: dedicated (pinned) CPU and shared CPU. | |
| 14:07:31 | sean-k-mooney | i dont think haveing a paralle implemantins and inplace updates are mutally exclcive | |
| 14:07:38 | stephenfin | I've no idea how we can make resource claims for existing instances that currently don't have anything claimed | |
| 14:07:42 | jaypipes | mnaser: and the ugliness of our NUMA and pinning code has borked how we think of the CPU resources. | |
| 14:08:04 | sean-k-mooney | stephenfin: they do have clims but they are all of resocue class vcpu | |
| 14:08:26 | stephenfin | yeah, so moving those from VCPU to PCPU | |
| 14:08:29 | jaypipes | stephenfin: by looking at the flavor and image extra specs. | |
| 14:08:33 | sean-k-mooney | stephenfin: so we need to modify there exiting claimes inplace as part of the reshape | |
| 14:08:40 | stephenfin | the migration is going to be hell | |
| 14:08:44 | jaypipes | yuuup. | |
| 14:08:48 | jaypipes | always is. | |
| 14:08:56 | sean-k-mooney | will it be any worse then the vgpu reshape | |
| 14:08:59 | stephenfin | we're going to handle the stupid stuff that can happen now, like shared and dedicated instances being on the same host | |
| 14:09:01 | jaypipes | as I've mentioned before, upgrade path is about 95% of the code and effort. | |
| 14:09:39 | mriedem | i thought you couldn't have shared and dedicated on the same host today, or is that a 'recommendation' but not enforced | |
| 14:09:47 | mriedem | and we just hope people use aggregates for sanity? | |
| 14:09:49 | sean-k-mooney | stephenfin: by the way today the vms cant mix pinned and flaoting instace so the only things we have to migrate are the pinned isntance and then just need to change the resouce class | |
| 14:09:50 | stephenfin | mriedem: yeah, the latter | |
| 14:09:53 | jaypipes | mriedem: recommendation. there is no way to enforce it. | |