support for it got added to Proxmox repositories, so there is no need to use
custom logic and manual fetching for this anymore.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
As termproxy only used this module from the huge proxmox-sys crate,
and this module was also only used here, it makes sense to move it
over there (and dropping proxmox-sys halved build-time from 8.5 s to
4.2 s).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If there is only one error, output in a single line, without any
excessive newlines at the end. If there are multiple errors, show them
in a bulleted list.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
We had two call sites deriving the directory "shard" where the task
log file is actually saved to, this can lead to ugly bugs and is
better done in a central single-source-of-truth way.
While at it factor out the creation of the log file (and it's shard
directory) to avoid crowding the WorkerTask new fn to much.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This mostly affected attribute parsing (due to the syn::Meta changes).
Also creating `DelimSpan`s for custom-built `syn::Attribute`s is a
bit... ugly.
Upshot: turns out we can drop some helpers in util.rs with the new
`syn::Meta` changes.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
previously we changed the internal type of the 'data' property
from Option<T> to T in the assumption the api always returns
'data:null'.
this is actually only the case when the api call succeeds. in an error
case there is no data property at all.
to fix this issue while behaving the same for 'data:null' we have to
revert to Option<T> for RawApiResponse but instead of always throwing an
error for 'data:null' in 'check' we now try there to deserialize from
Value::Null for T if there was no data. This will succeed for the Type
'()' which was the motivation for the original change.
The only downside is that the RawApiResponse now has a trait bound that
T is deserializeable, but was a requirement for using it anyway
(as there was no other way of constructing it)
Fixes: 271a55f ("client: remove option from inner RawApiResponse")
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
`Auto-Submitted` is defined in the rfc 5436 [1] and describes how
an automatic response (f.e. ooo replies, etc.) should behave on the
emails. When using `Auto-Submitted: auto-generated` (or any value
other than `none`) automatic replies won't be triggered.
[1]: https://www.rfc-editor.org/rfc/rfc3834.html
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
technically an empty string is not valid json, but when sending an api
request without any parameters, treating the empty body as an empty
parameter hash instead of an error, makes the the api more robust for
clients
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
note: not complete, there's other code to check and rework, but I had
this already done so commit it, better than nothing.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This moves the clean-up to happen up-front. That way one can still
inspect the test data after, e.g., a failed test.
Originally done almost like this in a patch from Fiona [0] that I just
overlooked, but now also factored out, avoid crowding the test code to
much with duplicate code.
[0]: https://lists.proxmox.com/pipermail/pve-devel/2023-June/057136.html
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the "main" repo only exists for Quincy to allow an easier transition
from Proxmox VE 7 to Proxmox VE 8, for when the enterprise repo got
added for ceph too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For now just duplicate the Ceph Quincy entries, as I want to avoid
using macros and we do not yet have support for enums inside enums
with the api macro.
Adapt and expand the tests slightly to have at least some simple
coverage there too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Files inside CARGO_TARGET_TMPDIR are only cleaned on `cargo clean`, so
tests that expect files to not exist need to cleanup themselves.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
