| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-11 | |||
| 11:58:24 | stephenfin | ta | |
| 12:03:01 | artom | gmann, cheers! (if you're still awake/around) | |
| 12:39:03 | cdent | aspiers: have you seen http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004779.html ? | |
| 12:39:41 | aspiers | cdent: yes, it's on my TODO list :) | |
| 12:39:47 | aspiers | still jetlagged from SUSECON | |
| 12:39:54 | cdent | roger, thanks | |
| 12:40:15 | aspiers | I saw that efried felt OK with the status quo though | |
| 12:40:37 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add in_tree field to RequestGroup object https://review.openstack.org/649534 | |
| 12:40:37 | aspiers | I'm inclined to agree that "don't do that" is a reasonable stance | |
| 12:40:37 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add get_compute_nodes_by_host_or_node() https://review.openstack.org/650877 | |
| 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 | |