all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Michael Köppl" <m.koeppl@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH] ui: lxc: set nesting to false for privileged container during creation
Date: Fri, 21 Mar 2025 11:38:25 +0100	[thread overview]
Message-ID: <eab5645e-6b0c-4091-9253-a0a884aa9632@proxmox.com> (raw)
In-Reply-To: <d8c57587-4a58-4043-bdc2-8134ce90a9de@proxmox.com>

Superseded byhttps://lore.proxmox.com/pve-devel/20250321103511.66722-1-m.koeppl@proxmox.com/

Thank you for having a look and your detailed suggestions!

> style nit: we mainly use `let` variables for new code as that has less confusing
> scope rules, i.e. variables declared through var are also available in the parent
> block scope.

Also thanks for this hint. Makes sense, will adhere to it for future patches.

On 3/21/25 08:58, Thomas Lamprecht wrote:
> Thanks for this patch, some comments inline.
>
> Am 18.03.25 um 17:14 schrieb Michael Köppl:
>> The current implementation is slightly misleading. When creating a
>> privileged container, the nesting checkbox is disabled but keeps its
>> current state. However, nesting is not enabled for privileged containers
>> even if the checkbox was set to true. Enabling nesting is still possible
>> through the Options menu.
>>
>> Signed-off-by: Michael Köppl<m.koeppl@proxmox.com>
>> ---
>> As an alternative to this, since we already discourage
>> the use of privileged containers [0], removing the checkbox for creating privileged
>> containers in the web UI might make sense. For the rare cases where they
>> are required, they can still be created using pct (although the question
>> remains whether privileged should be the default for pct create).
>>
>> [0]https://forum.proxmox.com/threads/debian-12-lxc-template-systemd-failures.151630/post-686850
>>
>>   www/manager6/lxc/CreateWizard.js | 11 ++++++++++-
>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/www/manager6/lxc/CreateWizard.js b/www/manager6/lxc/CreateWizard.js
>> index 62cda27a..c7ee56f7 100644
>> --- a/www/manager6/lxc/CreateWizard.js
>> +++ b/www/manager6/lxc/CreateWizard.js
>> @@ -7,6 +7,7 @@ Ext.define('PVE.lxc.CreateWizard', {
>>   	    nodename: '',
>>   	    storage: '',
>>   	    unprivileged: true,
>> +	    nestingEnabled: true,
> This works fine as is, but I think there is a better solution available here
> (see below) and such use of viewModel data binding can come back and bite one
> when extending/refactoring such code, as the code using it needs to be careful
> to not interfere with the automatic two-way binding to the field's value.
> I do not want to discourage using the viewModel, most of the time it can be
> fine and result in even nicer code overall, but it has its oddities.
>
>>   	},
>>   	formulas: {
>>   	    cgroupMode: function(get) {
>> @@ -69,14 +70,22 @@ Ext.define('PVE.lxc.CreateWizard', {
>>   			value: '{unprivileged}',
>>   		    },
>>   		    fieldLabel: gettext('Unprivileged container'),
>> +		    listeners: {
>> +			change: function(checkbox, value) {
>> +			    var viewModel = checkbox.lookupViewModel();
> style nit: we mainly use `let` variables for new code as that has less confusing
> scope rules, i.e. variables declared through var are also available in the parent
> block scope.
>
>> +			    if (!value && viewModel) {
>> +				viewModel.set('nestingEnabled', false);
> You could also avoid the intermediate viewModel variable that is used just once
> and use an optional-chaining operator, like:
>
>      checkbox.lookupViewModel()?.set('nestingEnabled', false);
>
>> +			    }
>> +			},
>> +		    },
>>   		},
>>   		{
>>   		    xtype: 'proxmoxcheckbox',
> FYI that component comes from our proxmox-widget-toolkit and is a small override
> of the original ExtJS checkbox. One thing it provides is a `clearOnDisable`
> config flag that if set to true should exactly provide the behavior you want
> here without needing to hook into the unprivileged change listener.
>
> See src/form/Checkbox.js in the proxmox-widget-toolkit for the rather trivial
> implementation of that flag.
>
>>   		    name: 'features',
>>   		    inputValue: 'nesting=1',
>> -		    value: true,
>>   		    bind: {
>>   			disabled: '{!unprivileged}',
>> +			value: '{nestingEnabled}',
>>   		    },
>>   		    fieldLabel: gettext('Nesting'),
>>   		},
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

      reply	other threads:[~2025-03-21 10:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-18 16:14 Michael Köppl
2025-03-21  7:58 ` Thomas Lamprecht
2025-03-21 10:38   ` Michael Köppl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eab5645e-6b0c-4091-9253-a0a884aa9632@proxmox.com \
    --to=m.koeppl@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal