[pve-devel] [PATCH qemu-server/container/toolkit/manager v3] fix #1934: add tags to guests

[Dominik Csapak]

On 11/20/19 8:10 PM, Thomas Lamprecht wrote:
> On 10/31/19 1:36 PM, Dominik Csapak wrote:
>> this series lets users add tags to guest configs
>> these do not have any concrete meaning but are intended to be used
>> by management software such as config management systems
>>
>> this is the basic implementation of this feature, in the next step
>> i want to do:
>> * get the tags in the /cluster/resources api
>>    this way we could show it in the gui, but more important, we can
>>    give the users a list of available tags to choose from in the selector
>> * maybe make the colors customizable, e.g. in the datacenter.cfg
>>    where an admin could give specific colors to a certain tag
>>    for instance:
>>       tagcolors: production=255,255,0,1
>>    in rgba values, we could query that and use it in our 'hash'
>>    function if the string exists in the custom color map
>>
>> changes from v2:
>> * rebase on master (drop applied patch, merge with lxc pending changes)
>> * move utilities to widget-toolkit
>> * prefix css classes
>> * remove tags from options and add edit button to the tags directly
>> * show 'no tags' when no tags are defined
>> * improve statusTxt style
>>
>> changes from v1:
>> * slightly different format (use [a-z...] instead of \w)
>> * add comment in JSONSchema
>> * better commit message
>> * add the tags to the status api call of guests (for gui)
>> * show the tags in the gui
>> * make the tags editable in the gui
>>
> 
> applied qemu-server and container, for the Webinterface part I'd like
> to see some changes/features..
> 
> * tag reordering (or show/save them sorted)

they already are shown in the order they are put in
this was done to not impose any order on the user

reordering can be done by, delete and add again
a reordering (via drag drop) can surely be done, but
will probably not be done in a day

> * editing a specific single tag
what for though? if one misspelled a tag, the user can
simply delete and add it again

(a tag is not inherently something persistent so editing
would be the same as deleting and adding a different tag)

> * tag edit window is pretty small and the UX is so lala, maybe one will
>    accustom to it, but maybe it would be better to just have a list of
>    tags (textfield or field-container)

we can make it bigger and as soon as we have a cluster wide list of 
tags, we can make use of the builtin (now disabled) drop down box
for selecting a pre existing tag

what did you imagine with your proposal? a simple 'free form' text field?

> * collapse tags if there are more than X (e.g., >3 and/or configurable
>    over browser settings), where the full list is then shown only on
>    mouse-hover, as it gets crowded fast.

this can make sense, but also kinda defeats the purpose to show them
in the gui in the first place (since i want to see all tags every time)

what probably would be better is to check the available space
(e.g. via browser width) and limit on a small monitor, but
show all if there is much space (kind of how we decide
to show one/two columns in the summary)


> * "No Tags" looks also a bit weird without visible separator, maybe
>    just prepend fa-tags symbol with a tooltip?

OK

> * an option to show them could also be the bottom of the VM/CT panel
>    "vertical menu", as stack - just as idea.

mhmmm, not a fan of this, because in most scenarios
there is more horizontal space available than vertical space, so
in a small monitor situation the list alread scrolls, showing
tags below there would hide the tags always then

> 
> The colors are somewhat OK, I mean at first really not, but I got became
> accustomed to it pretty fast.. If such auto-coloring is chosen it will always
> stay in contrast/fight a bit with the colors of the theme, IMO..

yeah, a further improvement on this can be a clusterwide(browserwide?)
overwrite of colors of specific tags, so that the users can
select the colors themselves

(this could be done e.g. in datacenter cfg?)

> 
> I omit the gui patches for now, imo some refinement, would be good here.
>