From: Dominik Csapak <d.csapak@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [RFC PATCH cluster/guest-common/qemu-server/container/manager] add backend profile support
Date: Fri, 3 Nov 2023 12:53:33 +0100 [thread overview]
Message-ID: <20231103115343.4133611-1-d.csapak@proxmox.com> (raw)
This series aims to provide profile support when creating guests (ct/vm)
so that users can reuse options without having to specify them every
time.
Sending as RFC because I don't quite like some things with the current
implementation and I'm not quite sure in which direction I should take
this. Also the GUI part isn't done yet and i wanted to see if the
direction is OK. (Sorry for the wall of text)
The major issues:
Using a single section config for both VMs and CTs make handling the
properties a bit weird. For now i prefix the options with "$type_"
so vm options are e.g. 'vm_ostype', 'vm_name', and so on while container
options are 'ct_ostype', 'ct_hostname', etc.
Using the same config/plugin system also makes using it a bit weird.
We have to register/init them in the api where they're used, but for the
cli we have to register only the available type and then init. This
makes it necessary to always set 'allow_unknown' while parsing the
config so that 'qm' doesn't trip over the container profiles...
A fix for both could be to separate the ct/vm configs into two files
(similar to how we did pci/usb mapping configs), that would fix the
prefixing, as well as the register/init issue (We have to have
separate APIs then ofc).
Another fix would be to extend the section config to allow different
properties of the same name for different types. Should be possible,
although we have to be careful to not break existing ones, and also
the API interface has to be separate for each type then (cannot really
have confiflicting api parameter schemas for the same name?)
We could also go in a completely different direction and create a config
per profile? (like we handle vm configs). Downside of that is, that the
current guest config handling part is partly in pmxcfs, so we'd have to
make that either more generic, or duplicate it for profiles.
(I don't quite like this one, since i think a single config for all
profiles should be enough? We could still do that later if we want
and the current way is impractical)
The minor issues:
* Is the priv path ok? /mapping/profiles/<id> feels a bit weird
* We should probably introduce a 'meta' property for ct like we have for
vms? we could record the profile there and also e.g. the template used
to set the container up.
* I did not restrict to any options of the config and i don't believe
this should make any issues (the critical ones are filtered out anyway)
but should we maybe have some kind of whitelist? if yes, which one
should be on there?
* there is still an issue with the docs generation, i'll have to look
into it
* I'm not quite sure how the UI for creating/editing profiles should
look like. For creating i could imagine a 'create profile from guest'
type of thing (thanks @mira for the idea), but for editing or creating
from scratch I'm a bit conflicted. We could simply show the profiles
in the tree, and reuse the vm hw/options panels for that, but does
that seem overkill? We could also leave that API only for now, and
make the gui later? (Using it in the wizard would also not be trivial,
but there the constraints are rather straight forward)
pve-cluster:
Dominik Csapak (1):
add profiles.cfg to cluster fs
src/PVE/Cluster.pm | 1 +
src/pmxcfs/status.c | 1 +
2 files changed, 2 insertions(+)
pve-guest-common:
Dominik Csapak (1):
add profiles section config plugin
src/Makefile | 2 ++
src/PVE/Profiles/Plugin.pm | 72 ++++++++++++++++++++++++++++++++++++++
2 files changed, 74 insertions(+)
create mode 100644 src/PVE/Profiles/Plugin.pm
qemu-server:
Dominik Csapak (4):
meta info: allow additional properties to be given
add the VM profiles plugin
api: add profile option to create vm api call
qm: register and init the profiles plugins
PVE/API2/Qemu.pm | 27 ++++++++++++++++++++++++++-
PVE/CLI/qm.pm | 6 ++++++
PVE/Makefile | 1 +
PVE/Profiles/Makefile | 5 +++++
PVE/Profiles/VM.pm | 37 +++++++++++++++++++++++++++++++++++++
PVE/QemuServer.pm | 29 +++++++++++++++++++++--------
6 files changed, 96 insertions(+), 9 deletions(-)
create mode 100644 PVE/Profiles/Makefile
create mode 100644 PVE/Profiles/VM.pm
pve-container:
Dominik Csapak (3):
add the CT profiles plugin
api: add profile option to create ct api call
pct: register and init the profiles plugins
src/PVE/API2/LXC.pm | 24 ++++++++++++++++++++++++
src/PVE/CLI/pct.pm | 6 ++++++
src/PVE/Makefile | 1 +
src/PVE/Profiles/CT.pm | 37 +++++++++++++++++++++++++++++++++++++
src/PVE/Profiles/Makefile | 4 ++++
5 files changed, 72 insertions(+)
create mode 100644 src/PVE/Profiles/CT.pm
create mode 100644 src/PVE/Profiles/Makefile
pve-manager:
Dominik Csapak (1):
api: add guest profile api endpoint
PVE/API2/Cluster.pm | 6 +
PVE/API2/Cluster/Makefile | 1 +
PVE/API2/Cluster/Profiles.pm | 230 +++++++++++++++++++++++++++++++++++
3 files changed, 237 insertions(+)
create mode 100644 PVE/API2/Cluster/Profiles.pm
--
2.30.2
next reply other threads:[~2023-11-03 11:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 11:53 Dominik Csapak [this message]
2023-11-03 11:53 ` [pve-devel] [RFC PATCH cluster 1/1] add profiles.cfg to cluster fs Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH guest-common 1/1] add profiles section config plugin Dominik Csapak
2023-11-06 9:22 ` Fiona Ebner
2023-11-06 9:34 ` Dominik Csapak
2023-11-06 10:12 ` Fiona Ebner
2023-11-06 10:32 ` Fiona Ebner
2023-11-06 10:38 ` Dominik Csapak
2023-11-06 11:38 ` Fiona Ebner
2023-11-03 11:53 ` [pve-devel] [RFC PATCH qemu-server 1/4] meta info: allow additional properties to be given Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH qemu-server 2/4] add the VM profiles plugin Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH qemu-server 3/4] api: add profile option to create vm api call Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH qemu-server 4/4] qm: register and init the profiles plugins Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH container 1/3] add the CT profiles plugin Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH container 2/3] api: add profile option to create ct api call Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH container 3/3] pct: register and init the profiles plugins Dominik Csapak
2023-11-03 11:53 ` [pve-devel] [RFC PATCH manager 1/1] api: add guest profile api endpoint Dominik Csapak
2023-11-04 8:34 ` [pve-devel] [RFC PATCH cluster/guest-common/qemu-server/container/manager] add backend profile support Thomas Lamprecht
2023-11-06 8:17 ` Dominik Csapak
2023-11-06 8:30 ` Dominik Csapak
2023-11-06 8:53 ` Thomas Lamprecht
2023-11-06 9:48 ` Dominik Csapak
2023-11-06 9:21 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231103115343.4133611-1-d.csapak@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox