Simply use onGetValues to assemble the dRAID config, if any.
We do not need to bother with setting values as this is only for
creates, never for edit/displays.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Check if stopping of a service (OSD, MON, MDS) will be problematic for
Ceph. The warning still allows the user to proceed.
Ceph also has a check if the destruction of a MON is okay, so let's use
it.
Instead of the common OK button, label it with `Stop OSD` and so forth
to hopefully reduce the "click OK by habit" incidents.
This will not catch it every time as Ceph can need a few moments after a
change to establish its current status. For example, stopping one of 3
MONs and then right away destroying one of the last two running MONs
will most likely not trigger the warning. Doing so after a few seconds
should show the warning though.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
If an OSD is removed during the wrong conditions, it could lead to
blocked IO or worst case data loss.
Check against global flags that limit the capabilities of Ceph to heal
itself (norebalance, norecover, noout) and if there are degraded
objects.
Unfortunately, the 'safe-to-destroy' Ceph API endpoint will not help
here as it only works as long as the OSD is still running. By the time
the destroy button is enabled, the OSD will already be stopped.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Ceph provides us with several safety checks to verify that an action is
safe to perform. This endpoint provides means to acces them.
The actual mon commands are not exposed directly. Instead the two
actions "stop" and "destroy" are offered.
In case it is not okay to perform an action, Ceph provides a status
message explaining why. This message is part of the returned values.
For now there are the following checks for these services:
MON:
- ok-to-stop
- ok-to-rm
OSD:
- ok-to-stop
- safe-to-destroy
MDS:
- ok-to-stop
Even though OSDs have a check if it is okay to destroy them, it is for
now not really usable in our workflow because it needs the OSD to be up
and running to return useful information. Our workflow in the GUI
currently is that the OSD needs to be stopped in order to destroy it.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
by sorting the lower cased variants, and only if they are identical
sort the original values with 'localeCompare'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
things that changed:
* removed 'add Tag' inline button with proper button that adds
empty tag
* don't require to confirm each tag, simply update the color "live"
* set a minimum width for the editing box, so that it's easier to click
* replace cancel/finish icons with proper buttons
* fix tagCharRegex for multichar text (necessary for paste)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
datacenter.cfg returns an 'ordering' option. parse that and
use it to order the tags when viewing. default is alphabetical.
With alphabetical ordering, drag & drop when editing is disabled and the
tags will be inserted at the right place. When saving, the sorted
order will be written into the config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
also allows to search for tags in the GlobalSearchField where each tag is
treated like a seperate field, so it weighs more if the user searches for
the exact string of a single tag
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
ui: ResourceGrid: render tags
with the 'full' styling
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
and update the treenodes when the tags change.
since we change the vm node text (which we pass through to the config
panel), we have to change how we generate the text there slightly
(otherwise that would include the rendered tags)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This is a wrapper container for holding a list of (editable) tags
intended to be used in the lxc/qemu status toolbar
To add a new tag, we reuse the 'pveTag' class, but overwrite some of
its behaviour and css classes so that it properly adds tags
Also handles the drag/drop feature for the tags in the list
When done with editing (by clicking the checkmark), sends a 'change'
event with the new tags
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
displays a single tag, with the ability to edit inline on click (when
the mode is set to editable). This brings up a list of globally available tags
for simple selection.
this is a basic ext component, with 'i' tags for the icons (handle and
add/remove button) and a span (for the tag text)
shows the tag by default, and if put in editable mode, makes the
span editable. when actually starting the edit, shows a picker
with available tags to select from
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
namely for 'tag-tree-style' and 'tag-colors'.
display the tag overrides directly as they will appear as tags
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This provides a basic grid to edit a list of tag color overrides.
We'll use this for editing the datacenter.cfg overrides and the
browser storage overrides.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
stores the color-map into a global list of overrides. on update, also parse
the values from the browser localstore. Also emits a GlobalEvent
'loadedUiOptions' so that e.g. the tags can listen to that and refresh their
colors
also saves the list of 'allowed-tags' into PVE.Utils
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
/cluster/options is now the go to place for getting these options
(until we have more options unrelated to the datacenter.cfg)
Also move the use of the console from VersionInfo to here, since
this will be the future place for ui related backend options.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To avoid returning unrelated information in the /version api call in
the future use the API endpoint that'd return the relevant
information basically anyway.
It contains most ui relevant options, like the console preference and
tag-style so allow these for users without 'Sys.Audit' on '/', for
others its unchanged, they still get the whole datacenter config.
We also add the list of allowed tags, while not strictly a datacenter
config, it's derived from the current users privileges and the
datacenter config.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Switch to the `proxmoxtextfield` widget and enable its `deleteEmpty`
option, which gives us that all for free and better.
Fix label/emptyText to title casing while at it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
that then also ensures it isn't submitted, which would fail
permission checks for non-root users when editing the vCPU.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Checking for only Sys.Console prevents users who actually have the
correct permissions (VM.Config.CDROM, VM.Config.Cloudinit) from adding
a new cloud-init drive. Some checks needed to be adapted so that editing
cloud-init devices was possible with VM.Config.CDROM instead of
VM.Config.Disk.
Signed-off-by: Leo Nunner <l.nunner@proxmox.com>
The kvm man page mentions that using 'c' will try booting from the
first hard disk, so the current '(no bootdisk)' text in the UI is not
accurate, and boot can still succeed.
Reported in the community forum:
https://forum.proxmox.com/threads/115800/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
previously the ui would allow adding all pools (even the default
ceph-mon pools) as storage. this could lead to issues when users did
use these pools as storage (e.g.: vms missing their disks after a
migration). hence, restrict the pool selector to rbd pools.
fails gracefully by reverting to the previous behavior if a pool has
no application assigned to it.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
Tested-By: Aaron Lauterer <a.lauterer@proxmox.com>
since ceph luminous (ceph 12) pools need to be associated with at
least one applicaton. expose this information here too so that clients
of this endpoint can use it.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
Tested-By: Aaron Lauterer <a.lauterer@proxmox.com>
instead of saving maximum 500 lines, count commands + lines, and only
if both are over the limit, truncate the command list
this way, at least the last 10 commands + output are always visible, and
no visible output is truncated, while still not letting the log
grow infinitely
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The new MTU field and the rate limit field are now in the advanced
section of the NetworkInputPanel to parallel the layout of the
NetworkEdit for VMs.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
The option to set the mtu parameter for lxc containers already exists
in the backend. It just has to be exposed in the web UI as well.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
we already have the 'mtu' option in the API, so we can just expose
that option inside the 'Advanced' menu for virtio network interfaces.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Moved the message tooltip below the advanced columns to avoid the line
break and make it more visually pleasing.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Since all tasks succeeded, previously no mail was sent in that case.
Note that the error passed to $self->sendmail() is added to the
subject of the mail if it is a single line or the beginning of the
mail otherwise. Thus changing the mail slightly compared to previously
for the case where the job-start hook fails and the case where the
job-end hook fails with mailnotification=always. But can be considered
an improvement, because the user sees the error right away.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
When the mode changes, we set the pool selector visible/hidden, but
we never disabled/enabled it. This tripped up the dirty state of the
form always showing the reset button as enabled.
Properly enabling and disabling the pool field fixes the dirty state
tracking.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
so that the default value and limits actually correspond to what will
be used. Defaults to values for cgroup v2, because that is the more
common scenario.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
so the frontend has the information readily available.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
