[pve-devel] [PATCH manager 1/2] add 'open console after create' checkbox for lxc

[Thomas Lamprecht]

Am 07/31/2018 um 08:47 AM schrieb Dominik Csapak:
> On 07/30/2018 04:20 PM, Thomas Lamprecht wrote:
>> Am 07/30/2018 um 03:06 PM schrieb Dominik Csapak:
>>> a typical use case for creating a vm is to finish the wizard,
>>> start the vm, and open the console to install the os
>>>
>>> we already have the 'start after create' in the backend,
>>> so implement the 'open console after create' in the frontend
>>
>> Hmm, couldn't we always select the newly created guest after creation?
>> This is quite a common mechanic in user interfaces, from my observation,
>> and I'd honestly like that, as I often have to search for the VM/CT
>> after creating as I've quite a few test guests and often do not set a
>> explicit VMID and/or guest name, so using the global search is not an
>> option. And even for the productive admin, which hopefully sets sane 
>> names, this could be helpful and intuitive.
>> This selection would be nice independent of the start after create
>> option - e.g., I often want to do task not possible with the wizard,
>> change firmware to OVMF, add a few disks or additional NICs ...
>> And the inline console could be also selected, unconditionally or if
>> 'start after create' was set, both OK IMO.
>>
>> This then would cover your use case, plus a few additional ones like 
>> mine described - without adding another checkbox.
>> And an user can always just hit back in the browser to get to the
>> previous panel if he still wanted to do stuff there, we have a state
>> manager.
>>
>> What do you think?
> 
> good idea in general, but a bit problematic to implement
> since we rely on /cluster/resources to update the tree (and subsequently 
> the vm panels) we would need a way to either wait on the tree
> to add a specific vm and switch then
> (which i find rather problematic, as this can take up quite some time,
> and switching then would be very weird)

yeah not totally ideal, explains why you open the external console...

> or to inject a vm into the tree before it is updated from the api
> (also a bit problematic, since we then would have to deal with
> updates that come after but do not include the vm (thus keeping it)
> but also with the situation that the vm is removed again when
> updating /cluster/resources before we saw it there at all)
> 

Forcing an resource update on successful task done callback should be a
safe way to get the VM, if still there, this should be also quite fast
to get. Injection could be done to, in the case it's not there after the 
next (or next + 1, to be sure) resource store update our it can be
considered as deleted, and just let the item-from-tree-deleted logic
handle it.

> or am i missing a third option?
> 

Hmm, a bit of another approach would be do have a task log window on
both guest types (CTs already have it, VMs use the one showing only a
progress bar) and have there two buttons 'Open Console', 'Go to VM', 
they could reside in the footer bar and only get enabled once we got
Task Done, but that are details. Could be the easier and less 'magic'
approach...