| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-14 | |||
| 15:31:44 | melwitt | alex_xu: cool, thanks | |
| 15:31:45 | bauzas | I can take a look | |
| 15:32:09 | alex_xu | np | |
| 15:42:31 | efried | alex_xu, johnthetubaguy: and also stephenfin: bauzas: gibi: Would you please have a look at https://review.opendev.org/#/c/580336 (delete on termination) and see if it's ready to +A today? | |
| 15:43:50 | bauzas | efried: /me opens a tab | |
| 15:44:18 | efried | sean-k-mooney, bauzas: I'm looking at the NUMA RP spec again right now. Based on comments I skimmed on my phone, I think we might have missed the boat on the `False` thing. But checking... | |
| 15:44:53 | bauzas | efried: when we discussed this with stephenfin, we agreed on splitting between non-NUMA and NUMA-aware nodes | |
| 15:45:13 | bauzas | so, if you say 'no' for a node, then you shouldn't get NUMA-aware instances | |
| 15:45:52 | bauzas | it's like 'no, I don't want to get a beer', but then the bar tender gives you one | |
| 15:46:08 | efried | bauzas: exactly, and there was a design hole for that in PS21. | |
| 15:46:49 | gibi | efried: ack | |
| 15:48:12 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support re-configure deleted_on_termination in server https://review.opendev.org/580336 | |
| 15:50:13 | bauzas | efried: ok, look then at the new revision and tell me then if you see some hole | |
| 15:50:19 | efried | bauzas: now I think I understand that you got rid of the fallback query completely, and on purpose. But that doesn't work. The upgrade issue that gibi and stephenfin identified still exists. | |
| 15:50:42 | efried | bauzas: Specifically: without the 'fallback query', NUMA-aware flavors can't land on `None` hosts. | |
| 15:51:06 | efried | But *with* the fallback query, NUMA-aware flavors will *also* (incorrectly) land on `False` hosts. | |
| 15:51:08 | bauzas | efried: ah, possibly | |
| 15:51:14 | bauzas | shit | |
| 15:51:55 | efried | So we need a) the fallback query, and b) some other design element to fix that second problem. | |
| 15:52:08 | efried | sean-k-mooney's suggestion of using an aggregate... that will work, but it seems like a big hammer to me. | |
| 15:52:16 | bauzas | or using another trait then | |
| 15:52:22 | efried | I think I would prefer marking `False` hosts with a `NO_NUMA_HERE` trait... yes | |
| 15:52:28 | bauzas | like HW_NON_NUMA | |
| 15:52:40 | bauzas | ok, I think we can do this | |
| 15:52:58 | efried | It's not pretty. But it's also *temporary*. Once all computes are upgraded to V where the conf is mandatory, we can get rid of that, because we also get rid of the fallback query. | |
| 15:53:16 | efried | please be sure to mention ^ that. | |
| 15:53:22 | efried | sean-k-mooney: does that work for you? | |
| 15:53:32 | bauzas | a trait for which nodes then ? | |
| 15:53:47 | efried | for U+ nodes where the conf opt is marked False explicitly. | |
| 15:53:47 | bauzas | for those having 'false' right? | |
| 15:53:49 | efried | y | |
| 15:54:06 | bauzas | ok, because then we will use the trait even after V | |
| 15:54:09 | efried | no | |
| 15:54:37 | efried | I mean, it wouldn't *hurt* to keep it, but it won't be needed after V. | |
| 15:54:41 | bauzas | if so, I'd prefer to have a trait on 'none' | |
| 15:54:45 | efried | can't | |
| 15:54:54 | bauzas | actually you're right | |
| 15:55:00 | efried | because we can't muck with T hosts | |
| 15:55:03 | bauzas | and yeah we can still have the trait | |
| 15:55:07 | bauzas | in V | |
| 15:55:23 | bauzas | and for example, stoppint to have it when we want (V or W) | |
| 15:55:26 | efried | We could. But we wouldn't need it anymore. But we can make that decision in V. Just mention that we *could* get rid of it if we wanted to. | |
| 15:55:33 | bauzas | agreed | |
| 15:55:44 | bauzas | okay I think I can write *something* | |
| 15:55:47 | alex_xu | bauzas: efried that spec I only not sure about the policy, that API is admin-only API. but I think his usecase is for normal user. maybe need to add new policy | |
| 15:55:51 | alex_xu | brinzhang: ^ | |
| 15:55:53 | bauzas | melwitt: +Wd https://review.opendev.org/#/c/602201/17 | |
| 15:56:24 | gibi | efried, brinzhang: I have to API related comments in https://review.opendev.org/#/c/580336/ | |
| 15:56:42 | melwitt | thanks bauzas! | |
| 15:57:15 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Proposal for a safer noVNC console with password authentication https://review.opendev.org/623120 | |
| 15:57:45 | brinzhang | alex_xu, bauzas, melwitt, gibi, stephenfin, efried: the nova-support-webvnc-with-password-anthentication spec was ready, please review, hope it can be merged before freeze SPEC day (Feb 14), thanks. | |
| 15:58:50 | brinzhang | alex_xu: thanks for your review of the noVNC spec | |
| 15:59:06 | alex_xu | brinzhang: np, quick reminder the title https://review.opendev.org/#/c/623120/27//COMMIT_MSG | |
| 15:59:35 | brinzhang | alex_xu: will update | |
| 16:01:17 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Proposal for a safer remote console with password authentication https://review.opendev.org/623120 | |
| 16:01:36 | brinzhang | alex_xu: done. | |
| 16:02:03 | efried | brinzhang: you're going to have a busy evening :) | |
| 16:02:20 | efried | brinzhang: did you see gibi's comment on https://review.opendev.org/#/c/580336/ above? | |
| 16:02:55 | brinzhang | efried: I will see it | |
| 16:10:23 | gmann | efried: sean-k-mooney : sorry missed your ping on microversion need discussion. I did not read the full context but if it is failing later and change converting 2xx->4xx , then we do not need microversion. | |
| 16:11:31 | efried | gmann: cool, thanks. | |
| 16:11:51 | efried | not sure what you mean by 'failing later'. The failure would happen via an API check. | |
| 16:12:10 | efried | and we're looking to convert a 4xx->2xx | |
| 16:12:40 | efried | IOW a flavor+image combination that we would previously bounce would now be accepted. | |
| 16:12:45 | gibi | efried, brinzhang, alex_xu: +A-d the vnc password spec | |
| 16:12:56 | efried | thanks gibi | |
| 16:13:18 | gmann | efried: ohk, and it is bounce currently in what situation ? | |
| 16:13:43 | openstackgerrit | Merged openstack/nova-specs master: Add Unified Limits Spec https://review.opendev.org/602201 | |
| 16:13:58 | efried | gmann: today you're not allowed to specify a hw:numa_nodes that would result in an uneven split, unless you also specify that split. | |
| 16:14:13 | efried | gmann: what sean-k-mooney is proposing is to tweak the algorithm so it's able to do that uneven split for you. | |
| 16:15:17 | efried | gmann: e.g. if your flavor+image says vcpus=5, hw:numa_nodes=2, previously we would fail. With the proposed "bug fix" we would succeed and give you a 3/2 split. | |
| 16:15:32 | brinzhang | gibi: how about "The ``delete_on_termination`` field is optional, if not specified, the server's BDM does not contains ``delete_on_termination``." | |
| 16:15:59 | brinzhang | gibi: thanks +A for vnc passwd spec | |
| 16:16:20 | gmann | efried: sean-k-mooney ah, got it. ok in that case, we should bump version for interoperability . | |
| 16:16:51 | efried | okay. I think that makes sense. | |
| 16:16:59 | efried | ergo, not happening in U :( | |
| 16:17:01 | gmann | gibi: brinzhang re: delete_on_termination spec - but volume id in url is old volume and in body it is new volume so those cannot be same. | |
| 16:18:02 | brinzhang | gmann: yes, it's true | |
| 16:19:10 | gmann | so we have to keep expecting the volume_id in request as mandatory. | |
| 16:20:14 | gmann | considering delete_on_termination as false by default make sense for me and consider only if it is explicitly mentioned in request | |
| 16:20:33 | brinzhang | - If only ``volumeId`` is required, just doing a swap volume. | |
| 16:20:45 | brinzhang | - If only ``delete_on_termination`` is required, just update the voume denoted by the ``volume_id`` in the URL path not the request body. | |
| 16:21:13 | brinzhang | these sentences make sense | |
| 16:22:32 | brinzhang | The default value of delete_on_termination is False, doesnot impact anything of the target volume, so I also think it ok have the default value | |
| 16:22:38 | brinzhang | gibi: what do you think? | |
| 16:24:30 | bauzas | efried: quick question, when we ask for a forbidden trait for all request groups, can we just say '&required=!HW_NON_NUMA' or need to ask for every request group ? | |
| 16:25:02 | bauzas | eg. &required_PROC1=!HW_NON_NUMA&required_PROC2=!HW_NON_NUMA | |
| 16:25:21 | bauzas | or sean-k-mooney or anyone that can answer this question ^ | |
| 16:25:38 | efried | bauzas: In this case it's for the fallback query. | |
| 16:25:46 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: Force refresh instance info_cache during heal https://review.opendev.org/679271 | |
| 16:25:54 | efried | So it can just be in the same group with the VCPU and MEMORY_MB resources. | |
| 16:26:26 | gmann | brinzhang: second statement seems like updating 'delete_on_termination' for already attached volume but via PUT which is nothing but swap volume API not updating the existing attachment. | |
| 16:26:26 | bauzas | efried: no, the fallback query is literrally Train | |
| 16:26:31 | efried | the point is we *want* to land on unreshaped hosts -- but only those with `None` | |
| 16:27:15 | bauzas | actually, you're right | |
| 16:27:16 | gmann | brinzhang: gibi i think, we should only target for newly replaced volume request can accept the 'delete_on_termination' for new volume. | |
| 16:27:50 | brinzhang | gmann: you mean we donot to change the old volume's delete_on_termination? | |
| 16:27:52 | bauzas | I'm already requiring NUMA-aware nodes, I don't need to ask in this query but in the fallback one | |
| 16:28:07 | bauzas | efried: thanks | |
| 16:28:10 | gmann | brinzhang: gibi sp that we can cover all the case where user can attach a volume (server boot, attach volume, swap volume) with 'delete_on_termination' info | |