Thomas Lamprecht [Mon, 24 Jun 2019 12:52:05 +0000 (14:52 +0200)]
ui: workspace: cope better with upgrade related false positive 401 HTTP codes
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>
Dominik Csapak [Wed, 19 Jun 2019 11:45:54 +0000 (13:45 +0200)]
ceph: mon destroy: do not stop monitor ourselves
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
Dominik Csapak [Wed, 19 Jun 2019 11:45:53 +0000 (13:45 +0200)]
ceph: mon destroy: remove from mon_host
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
Dominik Csapak [Wed, 19 Jun 2019 11:45:49 +0000 (13:45 +0200)]
ceph: mon create: add to mon_host with msgr2
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
Thomas Lamprecht [Tue, 18 Jun 2019 15:15:03 +0000 (17:15 +0200)]
ceph: setup symlinks: ensure global ceph config directory exists
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>
Dominik Csapak [Tue, 18 Jun 2019 13:42:48 +0000 (15:42 +0200)]
ceph: services: do not create rados object in get_services_info
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
Dominik Csapak [Tue, 18 Jun 2019 13:42:45 +0000 (15:42 +0200)]
ceph: init: update inital config for nautilus
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)
Thomas Lamprecht [Mon, 17 Jun 2019 10:41:16 +0000 (12:41 +0200)]
ui: migrate: add source node field and rebalance field positions
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 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.
network api : reload : don't allow openswitch at all
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)
Thomas Lamprecht [Mon, 10 Jun 2019 17:04:10 +0000 (19:04 +0200)]
gui: tree: add lock information to tooltips
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.
Thomas Lamprecht [Mon, 10 Jun 2019 16:51:39 +0000 (18:51 +0200)]
api: cluster/resources: add information about guest locks
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>
Christian Ebner [Tue, 11 Jun 2019 13:31:12 +0000 (15:31 +0200)]
fix #2190: Base64 encode SMBIOS value strings in order to allow more characters
On some occasions e.g. license checking, the manufacturer string in the
SMBIOS settings edit has to allow characters such as whitespaces.
https://forum.proxmox.com/threads/proxmox-and-windows-rok-license-for-dell.53236/
In principle SMBIOS allows to pass any zero terminated string to the
corresponding fields in the structure type 1 (System Information).
By base64 encoding the values clashing of the config is avoided.
Relies on the corresponding patch to qemu-server to pass parameter verification
and correct parsing.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
gui: vm: add CPU flag selector with tri-state awareness
This allows to select the tri-state (enforce on, enforce off, default
from QEMU+CPU Model) for each CPU flag independently.
For this a grid with a widgetcolumn is used hosting tree radio
buttons for each state. They're marked '+' for enforce on, '-' for
enforce off and the default has no label, as it isn't easy to add in
such a way that it does not confuses people and does not looks
completely ugly.. But, to help people which have a hard time figuring
out what the states mean, a fake column was added showing the current
selected state's outcome in words.
For show casing the new nice interface add all currently supported
flags from out API-
It could be worth to add some selected CPU model awareness, so that
flags are only enabled if they can make sense with the selected
model. But one should be able to add this relative easily with this
as base.
The hardcoded flag lists is not ideal, we should try to generate this
in the future, but here already qemu-server is lacking and this is
rather independent of the fact and can be done later one just fine
too.
Note that this /is/ an *advanced* feature so not visible for all
directly, while I try to document in short what a flag does it surely
isn't perfect and to short to explain all nuances, they should give
enough pointers to know if it's relevant at all (amd / intel cpu) and
for what one should research
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 6593d43d1047d335a3a95d37c6d2f51282697b26) Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Wed, 5 Jun 2019 13:59:37 +0000 (15:59 +0200)]
ceph: make ceph osd create api more readable
The aim of this patch is to reorder/rework the code of the api call
so that it gets more readable
it adds comments of what/why something is done, removes
code duplication between db/wal checks/creation
There are two changes in behaviour:
* when a device is given more than once via the api,
the user gets a parameter exception for the db or wal
with the information that the explicit defined devices must be
different
* we check the usage for db/wal before the worker, so that the user
gets instant feedback if a device is already in use
(this is more for api users than for gui users, since we do those
checks there also)
Dominik Csapak [Tue, 4 Jun 2019 12:47:53 +0000 (14:47 +0200)]
gui: ceph: add ServiceList component and use it
this is an abstraction for listing Ceph Services with a few improvements:
* start/stop/restart buttons for all services (incl. icons)
* a syslog button to view the syslog of that service
* correct reloading behaviour when creating/destroying
api: ceph mgr list: check if active_name is really set
As in a situation where we /had/ a manager but destroyed it this
key's value is a empty string, and if we pass that to the WebUI we
get strange results form of a ghost MGR entry with ExtJS auto-ID
generation as name -> pretty confusing.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Tue, 4 Jun 2019 12:47:51 +0000 (14:47 +0200)]
ceph: osd: rework osd destroy to work with ceph-volume
with this, osd destruction is left to ceph-volume if the osd was created
with ceph-volume, else our old code remains mostly the same since
we want to be able to destroy upgraded osds
Dominik Csapak [Tue, 4 Jun 2019 12:47:50 +0000 (14:47 +0200)]
ceph: osd: rework creation with ceph-volume
this completely rewrites the ceph os creation api call using ceph-volume
since ceph-disk is not available anymore
breaking changes:
no filestore anymore, journal_dev -> db_dev
it is now possible to give a specific size for db/wal, default
is to read from ceph db/config and fallback is
10% of osd for block.db and 1% of osd for block.wal
the reason is that ceph-volume does not autocreate those itself
(like ceph-disk) but you have to create it yourself
if the db/wal device has an lvm on it with naming scheme 'ceph-UUID'
it uses that and creates a new lv
if we detect partitions, we create a new partition at the end
if the disk is not used at all, we create a pv/vg/lv for it
it is not possible to create osds on luminous with this api call anymore,
anyone needing this has to use ceph-disk directly
service: add restart on-failure to pveproxy and pvedaemon
This way they can cleanly exit (with a SIGTERM or systemctl stop) but
will get restarted if killed or they abort, but only for
StartLimitIntervalSec= time period with a total maximal count of
StartLimitBurst= retries.
See `man systemd.unit` for details, default are 10s total
restart retry period with at max 5 total retry counts, after that the
unit will placed in the failure state. So this is a best effort try
with no real downside.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as already announced over two months ago[0], remove the unofficial
SheepDog plugin now completely. Besides that it was never fully
supported in Proxmox VE one of its main developer and ex-maintainer
declared it as abandoned[1], and thus just let's remove it, git
allows to resurrect it any time if a wonder happens anyway.
get_cluster_service: do not always call cfs_update
This was done to ensure the nodelist, which get_node_kv uses
internally to loop over all nodes, is filled. But, everything coming
through API/CLI already has a cfs_update called so this is not
required outside from development testing calls. As we normally do
not do this for such calls, cfs_update call is a prerequisite for
such things. The better solution would be handling this internally in
get_node_kv, e.g., by checking if $clinfo->{versionn} was set once,
and if not call to cfs_update, or maybe even better, so adapt the IPC
call for a possibility to get the KV status hash for all nodes.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-manager-legacy.git / log