We can have those in existing verify jobs configs, and that'd break
stuff. So, even while the "bad" commit got released only recently
with `2.1.6-1` (14 April 2022), we still need to cope with those that
used it, and using some serde parser magic to transform on read only
is hard here due to section config (json-value and verify currently
happen before we can do anything about it)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This reverts commit 7a1a5d206d.
We could already cause the behavior by simply setting ignore-verified
to false, aas that flag is basically an on/off switch for even
considering outdated-after or not.
So avoid the extra logic and just make the gui use the previously
existing way.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
else it's a lot of wasted space for the ordinary case, that hasn't
permanent maintenance modes activated, and even if, their admins
should be used to it, so not the best space/usability ROI there
either.
Just use the icon as visual clue and add a tooltip for the
maintenance mode info.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
matches what we do for (most) of such things in PVE since 7.0 there
and also what the disk management gui shows, further disks are sold
with SI units for their advertised capacity, so its more fitting
there too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit bd21a63b only fixed sync, not verify, and we can do better by
using a display-edit field.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
causes trouble with UI and is inconsistent as its still missing in
file restore (daemon)
We probably want to use a separate property to safe this to avoid
confusion with size.
This reverts commit 66ad63bac2.
Not only can we remove a few lines of duplicated code, we also get
the "link to repo management" for free.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
only ask the name of the current NS, not the full NS path to avoid
too long input requirements on deep levels.
needs a few smaller hacks, ideally we would pull out the basic stuff
from Edit window in some EditBase window and let both, SafeDestroy
and Edit window derive from that, for better common, in sync
features.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
after all we couldn't delete all that got requested, ideally this
should become a task where we can log what got deleted and what
not...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
no changes in interface for users of the crate as we re-export
anyway, so more for avoiding to crowd the datastore module to much
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
And make that opt-in in the API endpoint, to avoid bad surprises by
default.
If not set we'll only prune empty namespaces.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it maybe should still simple get dropped and replaced with
(empty)Text 'Root' or 'Root Namespace'
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
never makes sense to clear the value due to remote or remoteStore
change as we weren't enabled then in the first place.
This fixes clearing the currently set namespace on editing an
existing job, which always made it seem like the Root namespace was
selected, even if the originalValue was correct (thus the dirty-form
reset/ok behaviour still worked, making it even more confusing)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to avoid making it "jump" in the users face by immediately opening
the picker on window open.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This provides immediate feedback for adding the respective icon in
the navigation tree entry most of the time, and we can then increase
the query period of the datastore list store to the original 15
again, as it was lowered to 5 seconds for just this reason in commit
fbd6f54f39
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we query that store to add the datastore specific ACL paths to
improve UX there, this failed a while due the StoreManager lookup
always failing as the store wasn't registered in the StoreManager due
to using storeid vs. correct storeId
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for better re-usability in the future and it felt a bit odd to have
such specific logic in the sync job edit directly
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
other sizes can happen in legitimate and illegitimate ways:
- illegitimate: encryped chunks and bad actor client
- legitimate: same chunk but newer zstd version (or compression
level) can compress it better (or worse) so the
Ideally we could take the actual smaller chunk so that improved zstd
tech gets leveraged, but we could only allow to do that for
un-encrypted ones.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
they all still used some odd side effects of the tree structure to
decided what record type they operated on, just move them over to the
new `ty` record.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
without that one gets a "failed to lookup datastore X" in the log for
every datastore that is in read-only or offline maintenance mode,
even if they aren't scheduled for GC anyway.
Avoid that by first opening the datastore through a Lookup operation,
and only re-open it as Write op once we know that GC needs to get
scheduled for it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We sometimes need to do some in-memory only stuff, e.g., to check if
GC is already running for a datastore, which is a try_lock on a mutex
that is in-memory.
Actually the whole thing would be nicer if we could guarantee to hold
the correct contract statically, e.g., like
https://docs.rust-embedded.org/book/static-guarantees/design-contracts.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this not only makes the action disable/hide checks simpler, but also
prepares the view a bit for the idea of adding a new API endpoint
that returns the whole datastore content tree as structured JSON so
that it can be directly loaded into a tree store.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht