| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-11 | |||
| 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 | mriedem | if you're working on updates | |
| 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: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 | sean-k-mooney | any system the used to inpsect the flaovr vcpu field woudl now have to inspec the resouces dict | |
| 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:31 | dansmith | maybe we need a hangout | |
| 14:05:31 | jaypipes | dansmith: yes. | |
| 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. | |
| 14:10:13 | stephenfin | mriedem: It's all over the docs but who reads those | |
| 14:10:40 | sean-k-mooney | windriver have some downwstream only hacks to make mixed stuff work | |
| 14:10:47 | sean-k-mooney | or i guess i should say starlingx | |
| 14:10:52 | mriedem | i know they have their crazy floating vcpu stuff in starlingx | |
| 14:10:54 | sean-k-mooney | but we shoudl not port that | |
| 14:11:09 | mriedem | i'm not sure there is no way we could've enforced it, | |
| 14:11:11 | stephenfin | sean-k-mooney: You mean you can't have pinned and floating instances on the same host? If so, you know that's not true | |
| 14:11:15 | sean-k-mooney | ya so they were only able to do that because we dont enforce that | |
| 14:11:21 | mriedem | e.g. if cpu_allocation_ratio=1.0, you have to have dedicated cpus | |
| 14:11:37 | stephenfin | Yeah, we don't so we have to handle that | |
| 14:11:42 | sean-k-mooney | stephenfin: no you can but you shouldnt | |
| 14:11:51 | sean-k-mooney | with out the starlinx hacks | |
| 14:12:03 | stephenfin | and because you can, we're going to have to handle that | |
| 14:12:06 | jaypipes | mriedem: cpu_allocation_ratio=1.0 has nothing to do with pinned CPUs. | |
| 14:12:16 | dansmith | well, | |
| 14:12:20 | dansmith | it's all over this spec | |
| 14:12:20 | jaypipes | (which is part of the problem) | |
| 14:12:29 | stephenfin | hence my inclination towards draining hosts and moving them to other, newly configured hosts | |
| 14:12:39 | stephenfin | *moving the instances | |
| 14:12:40 | mriedem | my point was we could have used that as indication a host can only have dedicated cpu guests | |
| 14:12:53 | mriedem | but since we didn't do that, yeah we could have mixed on the same host i guess and have to deal wit it | |