so that a user can filter the underlying store, e.g. for type
Signed-off-by: Dominik Csapak
---
src/form/RealmComboBox.js | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/form/RealmComboBox.js b/src/form/RealmComboBox.js
index 5f61687..c57b52d 100644
--- a/sr
so that realmsync jobs get executed
Signed-off-by: Dominik Csapak
---
PVE/Jobs.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/Jobs.pm b/PVE/Jobs.pm
index 86ce9f693..5636844a7 100644
--- a/PVE/Jobs.pm
+++ b/PVE/Jobs.pm
@@ -7,9 +7,11 @@ use JSON;
use PVE::Cluster qw(cfs_lock_file cf
with this, users now can schedule realm sync jobs, instead of manually
pressing 'sync' or configuring a cronjob for 'pveum realm sync'
the access-control patch needs special care, since i try to sync
independent pve-scheduler calls across the cluster. in my tests here
it worked, but that does not
with that, the api call can now override the default option
that is set on the realm (if any) by providing 'none'
it was not possible previously to override the realm default
when one wanted no properties to delete
no other code changes are necessary since we only extract the
known values 'acl' e
a typical CRUD panel for adding/editing/removing realm sync jobs
the edit window has the typical job options like enabled, schedule, etc.
and the sync options from the existing sync window
we explicitely load the defaults on create (but not on update) when the
realm changes.
Signed-off-by: Domin
to be able to define automated jobs that sync ldap/ad
The jobs plugin contains special handling when no node is given, since
we only want it to run on a single node when that triggers. For that,
we save a statefile in /etc/pve/priv/jobs/ which contains the
node/time/upid of the node that runs the
if we don't manually set it to the empty string, it will use the
realm default, which might be unexpected. this way, the sync always
does what the user saw in the sync window.
Signed-off-by: Dominik Csapak
---
www/manager6/dc/SyncWindow.js | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ww
On 12/6/22 12:06, Dominik Csapak wrote:
if we don't manually set it to the empty string, it will use the
realm default, which might be unexpected. this way, the sync always
does what the user saw in the sync window.
forgot to fix the commit message, should be
"if we don't manually set it to '
The error messages for missing OVMF_CODE and OVMF_VARS files were
inconsistent as well as the error for the missing base var file not
telling you the expected path.
Signed-off-by: Noel Ullreich
---
PVE/QemuServer.pm | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/PVE/Qe
* fixed the inconsistensies in the error messages for missing OVMF
files
* added a check for OVMF_VAR files so that errors are not as cryptic
Noel Ullreich (2):
fix #4378: standardized error for ovmf files
catch missing ovmf file
PVE/QemuServer.pm | 7 ---
1 file changed, 4 insertions(+
check to see if the OVMF_VARS file actually exists. otherwise lines
3666 and 3673 break and give a cryptic error message
Signed-off-by: Noel Ullreich
---
PVE/QemuServer.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 2a2f1f7..38f3145 100644
---
Signed-off-by: Aaron Lauterer
---
pve-installation.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pve-installation.adoc b/pve-installation.adoc
index 15b6c6d..f0b8f26 100644
--- a/pve-installation.adoc
+++ b/pve-installation.adoc
@@ -296,7 +296,7 @@ manually.
In general
Reported in the forum:
https://forum.proxmox.com/threads/image-upload-fails-after-upgrading-from-7-1-to-7-3.119051/#post-516517
When additional headers existed in the request body, the upload failed.
With this patch, all additional headers get ignored.
Example: The following upload would fail be
When the Content-Disposition header wasn't the first, i.e. upload of
```
--XVH95dt1-A3J8mWiLCmHCW4roSC7-gBntjATBy--
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: form-data; name="content"
```
would fail. These headers now also get ignored, as we don't use them.
Fixed upload was
Am 02/12/2022 um 17:32 schrieb Stoiko Ivanov:
> ZFS 2.1.7 got released yesterday [0]
>
> the bulk of commits are fixes for issues discovered by static
> code-analyzers - while the bugs don't seem to have been hit in the wild it
> is still an improvment
>
> did some very superficial tests (migrate
Am 06/12/2022 um 14:14 schrieb Aaron Lauterer:
> Signed-off-by: Aaron Lauterer
> ---
> pve-installation.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
applied, thanks!
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://
To get more details for a single OSD, we add two new endpoints:
* nodes/{node}/ceph/osd/{osdid}/metadata
* nodes/{node}/ceph/osd/{osdid}/lv-info
The {osdid} endpoint itself gets a new GET handler to return the index.
The metadata one provides various metadata regarding the OSD.
Such as
* process
Render the OSD listening addresses a bit nicer and one per line.
Signed-off-by: Aaron Lauterer
---
changes since
v3:
- rebased
v2:
- improve and simplify the first preparation steps
- if regex matching fails, show the raw value
www/manager6/Utils.js | 15 +++
1 file changed, 15 inse
This new windows provides more detailes about an OSD such as:
* PID
* Memory usage
* various metadata that could be of interest
* list of phyiscal disks used for the main disk, db and wal with
additional infos about the volumes for each
A new 'Details' button is added to the OSD overview and a d
This patch series adds 2 new API endpoints for OSDs to fetch more
detailed information about a single OSD. One for overall information and
one for a single volume (block, db, wal).
More in the actual patches.
Series got [0]:
Reviewed-by: Dominik Csapak
Tested-by: Dominik Csapak
Changes since
Am 06/12/2022 um 14:11 schrieb Noel Ullreich:
> check to see if the OVMF_VARS file actually exists. otherwise lines
> 3666 and 3673 break and give a cryptic error message
I do not think that referencing lines in the commit message is helpful, rather
just describe it in general, e.g., ".. otherwise
Am 02/12/2022 um 13:59 schrieb Fiona Ebner:
> No functional change is intended.
>
> Signed-off-by: Fiona Ebner
> ---
>
> Popped out while trying the other approach mentioned in:
> https://lists.proxmox.com/pipermail/pve-devel/2022-December/055091.html
looks ok, having it in a separate method op
22 matches
Mail list logo
