it's not immediately obvious that they can be specified more than once
otherwise.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this is only used for CLI synopsis/usage strings, the API viewer already
prints the full type text in a correct format. the old variant was also
rather misleading, since on the CLI we don't pass in an array, but each
item as its own parameter.
noticed this while working on the pull/sync filtering series, but it
affects quite a lot of stuff, among other things the Updater and
Deleteable CLI, e.g. from `man proxmox-backup-manager`:
> --delete <array>
> List of properties to delete.
vs.
> --delete disable|validation-delay
> List of properties to delete.
But some of them might only have <string> as the item type text,
which is not much nicer but also not really worse.
The whole "List of .." is confusing anyway, but not easily solvable,
since the description is used for
- API dump/viewer (where it is a list/array of ..)
- usage message/man pages (where it's a parameter that gives a single
element, but it might be passed in multiple times to construct an
array)
Also, for some common occurrences, the item description is too
generic, and it's not possible to override the description for
external types with the current api macro.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[ Thomas: Added more context that was in the diffstat of the path ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this prevents us from using it under certain conditions and it's
actually not necessary, so drop them
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
* Updatable is now named UpdaterType
* UPDATER_IS_OPTION is now assumed to always be true
While an updater can be a non-optional struct, being an
updater, all its fields are also Updaters, so after
expanding all levels of nesting, the resulting list of
fields can only contain optional values.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This way we can assign `API_SCHEMA` constants to `Option`
types.
Here's why:
The api-macro generated code usese `T::API_SCHEMA` when
building ObjectSchemas.
For Updaters we replace `T` with
`<T as Updatable>::Updater`
This means for "simple" wrappers like our `Authid` or
`Userid`, the ObjectSchema will try to refer to
`<Authid as Updatable>::Updater::API_SCHEMA`
which resolves to:
`Option<Authid>::API_SCHEMA`
which does not exist, for which we cannot add a normal
`impl` block to add the schema variable, since `Option` is
not "ours".
But we now have a blanket implementation of `ApiType` for
`Option<T> where T: ApiType` which just points to the
original `T::API_SCHEMA`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
#[api]
struct Foo {
field: Bar,
}
does not require the use of
#[api(
properties: {
field: {
type: Bar,
},
},
)]
anymore
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Some file systems don't support renameat2's RENAME_NOREPLACE
flag (eg. ZFS), at the some time, some other file systems
don't support hardlinks via link (eg. vfat, cifs), so we now
try both: first the rename (since it's more efficient), then
link+unlink for the rest.
If both fail, the file system is simply not supported for
our purposes anyway...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
we are not really compatible with pbs1, needs a stable-1 branch if we
need to backport something
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this major release still needs to have an incompatible, the next one can
drop setting a protocol client-side, and the one after that can remove
the protocol handling on the server side.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
we do not support websocket subprotocols, but for compatibility with
current clients (novnc, pve-xtermjs) we have to reply with the one requested,
else this is a protocol error and browsers will error out
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we never actually sent text frames, nor did any client request them.
Also, no validity check ever ocurred, so technically it was against
the spec.
Simply remove the code handling sending out text frames. If we need
to actually handle that, we can always create a 'WebSocketStringWriter'
or similar.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
