Posted	Nick	Remark
#openstack-nova - 2020-02-14
15:10:57	melwitt	alex_xu: hey, did you mean to hold off on +W on the unified limits spec? https://review.opendev.org/602201
15:25:17	openstackgerrit	Alexandre arents proposed openstack/nova master: Avoid allocation leak when deleting instance stuck in BUILD https://review.opendev.org/702368
15:31:27	alex_xu	melwitt: I'm ok with spec, just see bauzas whether want to look at that again
15:31:42	bauzas	alex_xu: the unified limits one ?
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.

Earlier   Later