The attribute help promises "a specific device name", but getinstalldisk
only understood "m2" and "/dev/<name>". A plain "nvme0n1" aborted the
install with "Unknown deployment.storage specification", and a
"/dev/<name>" that matched no disk was silently ignored, so the OS went
to whatever disk the default ordering picked. For an attribute meant to
pin the OS disk that is the dangerous failure mode.
Accept a kernel name with or without /dev/ and resolve /dev/disk/by-*
links to their kernel name, so a disk can be pinned by a stable path.
When nothing matches, fail with "No disks match" like the m2 filter
already does. Document the accepted forms in the attribute help.
confluent_client and confluent_server rpms took the PEP 440 version
setup.py needs, 4.0.1.dev5+g..., which rpm sorts after 4.0.1: a
released package did not upgrade a development build of it. Stamp the
rpm with the ~dev form the other packages already use and keep .dev only
for setup.py and the sdist name. The debs already sort right, since
stdeb rewrites .dev to ~dev.
Python 3.13 dropped crypt from the stdlib, and openSUSE Leap 16 packages
neither legacycrypt nor crypt_r, so the server did not start there
without a pip install. Both of those only call crypt(3) from libcrypt,
which every distribution ships, so do that through ctypes as the last
resort, serialized because crypt(3) returns a static buffer. Its hashes
match the stdlib module byte for byte.
Move the import chain both callers carried into confluent.pwcrypt. The
legacycrypt Recommends is no longer needed.
Neither is packaged by EPEL or Ubuntu, so the hard dependency made the
server uninstallable there without --nodeps or a stub package. Both are
already optional in the code: httpapi drops passkey support when
webauthn does not import, and the Lenovo IMM2 BIOS settings path reports
the missing module as unsupported functionality. Recommend them instead,
as the SUSE branch already does for webauthn.
See xcat2/confluent#192.
For one, at the time an XCC emits a NOTIFY, it's DeviceDescription.json is also very sluggish. Extend timeout
knowing this may be delayed.
Further, if snoop comes back with only one address family, do not
perturb existing address families.
- A manager that is not a confluent node is pinned on the guest's node
(pubkeys.tls_hardwaremanager), as the console already does.
- user@realm!tokenid with the token secret is accepted as the login;
VNC needs a password login and says so.
- Route every API call through one checked path: non-2xx answers raise
with PVE's message, a 401 logs in again, a migrated guest is re-mapped.
- Report login failures other than 401 instead of a TypeError.
- Power changes are bounded and reported per node; 'on' when on is a
no-op; every live QEMU state counts as on.
- Read and set the boot order in every form PVE accepts, keeping disks.
- Stop toggling Content-Type on the shared client headers.
- Inventory from the current config, all SMBIOS forms.
- Refuse ambiguous guest names; skip templates.
- Keep the serial console alive and report how it ends.
- Let the self-test run without a config manager.
asyncssh relationship with cryptography can be messy, but it's not up to us, so discard those.
Change osdeploy to not use fork to avoid that deprecationwarning.
The vncwebsocket URL used the name of the Proxmox node running the
guest as host. That name often does not resolve on the management
node, and the fingerprint checked is the one of the manager anyway.
Connect to the manager instead, which forwards the websocket to the
right node.
Some devices have multiple BMCs, but we don't know
the 'right' one.
In such a scenario, search for BMC NICs for any that match the address we are using.
In the process of reworking cache logic, a temporary disabling was left in.
Before the logic change, 'cache' of '1' meant 'True', but the intent was a max age to decline to reply. This allows very close together requests to be cached.
Proivde support for API keys. Users can register by doing a POST like:
/confluent-api/sessions/current/apikey/create with body of '{"expiration":null}
API keys can be reset by doing a POST to /confluent-api/sessions/current/apikey/revokeall
A secret is provisioned per user to allow them to clear all keys, while remaining mostly stateless to avoid having to manage every key server side.
Markus Hilger
Jarrod Johnson
Laurence
Jarrod Johnson