While we nowadays can work much better with package upgrades relating
the cluster stack it still happens that a pve-cluster upgrade can
produce a false-positive 401 (auth failure) code for a currently
valid ticket, e.g., because a pmxcfs lock was requested but the
pmxcfs was currently not mounted due an upgrade triggered restart.
A frequent case for a few false positive 401 is also a cluster
creation, especially if not done over the web GUI.
Thus add a counter, which gets set to 0 on each successful login or
ticket renewal and gets increased on each 401 error. Only show the
logged out window if we get five or more 401 responses. While 5 may
sound a bit much one needs to remember that we always have quite a
few API call in flight (resource update store, stores from current
panel ...) and thus, if one got really auth denied it will still show
quite fast (1 to 5 seconds, depending on which panel is currently
opened). Further, the backend naturally does not allows to do
anything during this time, this has no security implications
whatsoever.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
a 'mon remove' does this already for us, so do not stop it
this lead to a race where we could stop the next to the last monitor
before it was removed from the cluster, leading to a state
where two monitor were needed for quorum, but only one did exist
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we need to remove an ip, ip:port or a ipvector from monhost
so use multiple regex search and replaces for this
this looks not really nice, but due to the strange format
of the line (e.g. ',' is a seperator inside and outside of a vector,
also ipv6 adresses may be surrounded with [] but so are vectors),
i found no better way
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
otherwise it is possible that multiple users create monitors at the same
time, resulting in a wrong ceph.conf and probably worse
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in nautilus, the default msgr protocol is v2, but it has to be
explicitely given to monmaptool, also we don't want to use the
monitor sections anymore so only update mon_host
ceph can cope with mixed mon_host and monitor sections, so this is
not a problem
also the ceph-create-keys part is not necessary anymore since
this is done by the monitor itself now
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by using our new 'get_services_info'
this already checks for nautilus+ style 'mon_host' key in the ceph.conf
for the ip address
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Make clear thet the 5.x is also supported and reword a bit as
"5.X/4.X/3.X/2.6" is a bit hard to read, so use "5.X - 2.6"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
normally this gets created on package installation, but could be
deleted, e.g., by a debug purge. As it costs nothing to create just
do a mkdir on it, which does not fails if it already exists..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it makes no sense to have the mon key inside the client.admin.keyring
also the order and operations did not make much sense
also create the client admin keyring when creating the config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if we already have a monitor, we can try to get the public_network via
the ceph configuration database
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in a case where we cannot connect to any monitor, we did not get
any info even if we have them via the pmxcfs
so get the RADOS object in an eval, and get the info we have from the
config/pmxcfs, and set the state to unknown if we cannot query via RADOS
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we always gave one, and the only reason why it could be undef
is that we could not connect, so it makes no sense to try again
and add unecessary time to the api call
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since we do not support creating filestore osds anymore, drop
the journal size from the config
and move the keyring from global to client
this makes it possible to omit the osd keyring path
(which was the default but got overwritten from the global section)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
with this one can see the avail/capacity columns in full even if we
have "xyz.ab GiB", i.e., the max length this can be.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This makes the window more symmetric, and additional has the
following small advantages:
* to the left we now have static fields only, user modifiable ones
are all to the right (with shorter distance to the migrate "submit"
button here)
* if one starts the migration from the tree's context menu it may not
be really clear where the VM currently is located at, so showing
the source node can help (especially on bigger clusters with a
huge target node list)
* more symmetric
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch depends on:
qemu-server: e1f0fbf4448b374eb9a19502aee565adb5be7ec0
This patch refactors the migrate ui to incoperate the viewmodel approach
which should help if we need to add functionality in future iterations.
Additionally it is now possible to migrate with local disks.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
ifupdown2 reload can't work with openswitch until we implement
ovs.
I don't think that too much users are mixing ovs && bridge anyway.
It's possible to use ifupdown2 with ovs for ifup/down with ifupdown script,
but config need to be changed, and I don't have tested too much.
(maybe add a conflict in ifupdown2 package with openvswitch package for now)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This was for vxlan interfaces and fixed in ifupdown2 with my last patches.
simply reload network, and if we still have errors, we can use ifquery to check them later
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Add classes for suspended, suspending and migration.
They use the same symbol as in the buttons for consitency, size is a
bit smaller to fit better for the tree.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was already proposed by Dominik[0], but it was was wished for a
faster backend backing of this[1], and as with most wishes one needs
to either be content with what's there or (try) to improve it one
self.. So with the IPCC approach proposed as backing for this I'd
like to add this again. It differs from [0] a bit, first it's rebased
as parts of the tooltip stuff got already applied[2].
I use "Config locked (<LOCK>)" as text for this, as it
1. Clarifies what the lock symbol means, which is always a good thing
for tooltips
2. repeating the lock symbol here again would show the users three
lock symbols at the same time if the VM was selected in the tree
(the tree one, the VM config panel one, and this tool tip one)
this is a bit much, so don't do it.
[0]: https://pve.proxmox.com/pipermail/pve-devel/2019-February/035829.html
[1]: https://pve.proxmox.com/pipermail/pve-devel/2019-March/035930.html
[2]: https://pve.proxmox.com/pipermail/pve-devel/2019-March/036165.html
Co-developed-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
using the new get_guest_config_property helper from pve-cluster,
which allows us to get this info with relatively low overhead.
With a somewhat realistic setup of 303 guest configurations here my
API call timing changes from ~ 24 to 26 ms without this to 26 to 28
ms with this patch applied, which seems reasonable.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
make the message a bit more informative (with help from thomas), namely
mentioning the ability to change/increase the limit.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
