Update node restrictions to reflect that the storage is not available
anymore on the particular node. If the storage was only configured for
that node, remove it altogether.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
slight style fixup
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
By adding the keyring for RBD storage or the secret for CephFS ones, it
is possible to add an external Ceph cluster with only one API call.
Previously the keyring / secret file needed to be placed in
/etc/pve/priv/ceph/$storeID.{keyring,secret} manually.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
similar to the existing encryption key handling, but without
auto-generation since we only have the public part here.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
First, doing such things can make client work slightly easier, as the
submitted values do not need to be made available in any callback
handling the response.
But the actual reason for doing this now is, that this is a
preparatory step for allowing the user to download/print/.. an
autogenerated PBS client encryption key.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the delete parameter get's injected by the SectionConfigs
updateSchem, but we need to handle it ourself in the code
This makes the following possible:
pvesm set STORAGEID --delete property
Also the API equivalent is now possible. Adapted from the HA
managers Resource update API call.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as described in #862:
> I experienced a problem with ISCSI portal when using a hostname and
> not IP.
> The GUI resolves the hostname to an IP and writes it to storage.cfg.
> As my setup requires hostnames, i needed to change the config
> manually back to the hostname which is working fine.
>
> Why is this conversion done? If I enter a hostname, i want to have a
> hostname. If i enter an IP address i want to have an IP address.
This makes sense to me, a feature of using domains is that they
are/should be resolved when actually using (i.e., connecting to them)
so resolving it once on add does not seems like a good idea (if I do
not miss something - as this is a classic "imported from SVN" I do
not have any rationale to look at).
So save the work and pass it as is.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
on_add_hook allows to encapsulate storage specific add steps, like
copying a keyring (RDB) or creating a volume group (LVM) in a clean
manner.
The same for deletion with on_delete_hook, here all should be cleaned
up, as much as possible.
Until now, this was done directly in the api config CREATE and DELETE
code, respectively, with a series of
if ($storage_type eq 'foo) {
...
} elsif ($storage_type eq 'bar') {
...
}
which isn't really that nice...
Another nice result of this approach is that also external plugins
can use those hooks and to their setup/cleanup steps sanely.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as else we write it to /etc/pve/storage.cfg which is readable by
www-data, a not really private group...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In this patch the nodes will be deleted if the nodes parameter comes with a empty string.
We need this in the GUI when update the nodes in the config to reset if a nodes.
If we do not erase the empty hash the storage online check would be skipped.
Also the password and user would not be verified.
