Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-14
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
16:28:13 efried right, so:
16:28:13 efried - U hosts with `False` we a) don't reshape, and b) mark with HW_NO_NUMA
16:28:13 efried - pre-U and `None` hosts we a) don't reshape, and b) *don't* mark with HW_NO_NUMA (in the case of pre-U hosts, we couldn't mark them with anything even if we wanted to)
16:28:13 efried - The fallback query *forbids* HW_NO_NUMA so we *won't* land on U/False hosts.
16:28:22 efried correct
16:30:38 brinzhang gmann: I know you mean, but the old volume is not support to configure the 'delete_on_termination' after it was attached, or booted(bfv)
16:30:58 brinzhang gmann: I think change the old volume's 'delete_on_termination' make sense
16:33:18 gmann brinzhang: but user can do it always while it was attached originally in server boot or POST /servers/{server_id}/os-volume_attachments/{volume_id}
16:34:56 brinzhang gmann: I know, but it just a decision while the server booting or attaching a volume, while the server run a long time, the user may will change it.
16:35:02 openstackgerrit Merged openstack/nova-specs master: Proposal for a safer remote console with password authentication https://review.opendev.org/623120
16:35:39 gibi gmann: as I read the goal of the spec is to change the delete_on_termination flag of an already attached volume. But now I see another usecase when you swap a volume then you need to define what should be the delete_on_terminate value of the new volume
16:35:46 gibi brinzhang: do you need both use case?
16:36:34 brinzhang gmann: In our project, we met such customers who were unwilling to suspend the virtual machine business and wanted to change the volume configuration, but were unwilling to keep mounted volumes when cleaning up the servers.
16:36:37 gmann yeah, i feel later case make sense and with that we cover all cases where user can attach volume and specify the 'delete_on_termination'
16:37:04 melwitt I'm just in the peanut gallery but I would think yes, do both right? if you're swapping in a new volume, you'd want to be able to say whether it should be deleted on termination

Earlier   Later