Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-14
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
16:37:26 melwitt otherwise that would be the one case where you can't say it
16:38:53 gmann yeah, for new volume yes. but i am not getting to do it for old attached volume. or at least via this API which is nothing but swap volume.
16:40:10 brinzhang Looking back at the history of the spec, we can't find a better nova API to make changes to this. The current API is suggested by mriedem.
16:40:36 melwitt I think the main thing they want to do is change for old already attached volume :) but I do agree, adding this would be overloading the swap volume API (not ideal), as lyarwood mentioned on the review awhile back
16:40:45 gibi brinzhang: so you confirm that you would like to have both use cases covered
16:40:54 gmann true.
16:41:23 gmann brinzhang: you cannot delete the attachment and re-attach with 'delete_on_termination' ?
16:41:40 gibi not for bfv
16:41:51 gmann ohk
16:43:06 brinzhang gmann: of course, I can, but while the admin need to manager more than 100+ instance, it will be have some problem to maintain
16:43:56 gmann i am reading the recommended use case of this API from api-ref in warning section - https://docs.openstack.org/api-ref/compute/?expanded=update-a-volume-attachment-detail
16:44:03 brinzhang gibi, gmann, melwitt: so you all suggestion is only do the swap's volume to set the 'delete_on_termination' for the new volume?
16:44:43 gmann and making this APIs for this new case means we are over-scoping this API which can lead this to more-confused API than it is today
16:44:55 gibi brinzhang: I would be happy to support changing delete_on_terminate for attached volume I just see that gmann has a problem with the API design
16:45:49 gibi as a note: my EndOfBusiness is closing really fast
16:46:11 gmann https://docs.openstack.org/api-ref/compute/?expanded=update-a-volume-attachment-detail#update-a-volume-attachment
16:46:37 gmann 'This API is typically meant to only be used as part of a larger orchestrated volume migration operation initiated in the block storage service'
16:46:40 gibi if you can figure out a good place for this in the API I will support both use case, if there is no good place for the first case in the API then I can also support implementing only the second case in U
16:46:55 lyarwood FWIW I think this is the correct place for the API
16:47:01 lyarwood once we've removed the swap stiff
16:47:04 lyarwood stuff*
16:47:24 lyarwood I wanted to look into moving it into an instance action as with extend_volume etc
16:47:59 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.opendev.org/552924
16:48:03 bauzas I'm burned from this week
16:48:23 gmann or in PUT /servers ?
16:48:25 bauzas efried: I'll leave you look again if you agree with https://review.opendev.org/552924
16:48:38 bauzas stephenfin: sean-k-mooney: your help could be nice ^
16:48:46 efried looking right now
16:48:46 bauzas gibi: too if you're not burned too ^
16:49:31 bauzas efried: not a big deal, just wrote another paragraph https://review.opendev.org/#/c/552924/22..23/specs/ussuri/approved/numa-topology-with-rps.rst
16:49:39 brinzhang gmann: PUT /servers is the PS3 solution
16:50:26 brinzhang Or I can say is our first idea for the 'delete_on_termination'
16:51:00 gmann gibi: lyarwood brinzhang melwitt :in reality this swap volume API has been always in question and diverted the use case from it was originally. I remember one failure in this API when one of our customer were doing swap to vole2 and swap back to vol1 and so on. i do not know why :)
16:51:25 gibi sorry folks I have to leave.

Earlier   Later