On Mon, Jul 18, 2016 at 07:44:10PM +0200, Tobia Conforto wrote:
> > Ah, that makes sense. Would be great if you can assemble a prototype (to
> > see if it works well)?
>
> Sure. I'll see what I can do.
Perhaps a socat coproc with the -T option? It should be installed since
we already need it:
#
> Is this something that's already available? My pvedaemon is not listening to
> any unix sockets.
Oh, It uses a local tcp port...
> Otherwise, we might as well have it listen on a specific socket, say
> /var/run/.pve_completion, with a simple protocol such as the example I made
> before. Then
> Ah, that makes sense. Would be great if you can assemble a prototype (to see
> if it works well)?
Sure. I'll see what I can do.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> On July 18, 2016 at 7:29 PM Tobia Conforto wrote:
>
>
>
> > This would span one coproc per bash/terminal session? I guess that is a bit
> > too much.
>
> Is it?
>
> It would spawn and keep around one coproc per user, per bash, per command
> (pct, qm, pvesm, vzdump...) but only if the use
> For unix sockets, you can query the unix user of the connecting peer - so
> this is not really a problem. Also, you can connect to pvedaemon (not
> pveproxy), so connections are simple http (unencrypted). But you still have
> the overhead of spawning curl...
Is this something that's already a
> This would span one coproc per bash/terminal session? I guess that is a bit
> too much.
Is it?
It would spawn and keep around one coproc per user, per bash, per command (pct,
qm, pvesm, vzdump...) but only if the user has been using that particular
command in the *last N minutes* (5 minute
> The problem with the REST API (apart from the overhead of spawning Curl
> processes and doing SSL handshake and encryption) is that it requires
> authentication: you don't want to save your PVE password in a bashrc file, or
> enter it at the prompt just to have auto-complete.
For unix sockets, y
> I can see an easy solution in the form of coprocesses[1]. The autocomplete
> bash function would spawn the command on demand as a coprocess and then
> communicate with it over private pipes, with a simple text protocol. For
> example: send one line with the text the user typed; receive one line w
> Using bash is clumsy, because you cannot use the existing libraries. Instead,
> I suggest to use API calls, maybe using curl or wget? This would avoid the
> perl startup overhead. (maybe we need to adopt the http server to be able to
> return a suitable text format).
The problem with the REST
> Thank you for your pointers.
>
> I'll make sure to post a patch if/when I get something decent running.
>
> > completion already feels a bit sluggish
>
> I agree. In fact, I'm wondering if it wouldn't be more useful for me to
> rewrite the completion code as native Bash functions, with as few
Tested on pretty old 7-mode FAS2040 on
iSCSI, but shuld also work on newer clustered setups and over FC media.
Plugin needs non-default for PVE packages: multipath-tools, scsitools. Also
option ``uid_attribute ID_WWN_WITH_EXTENSION'' and to blacklist all in
multipath.conf are required.
v2 patch. C
Thank you for your pointers.
I'll make sure to post a patch if/when I get something decent running.
> completion already feels a bit sluggish
I agree. In fact, I'm wondering if it wouldn't be more useful for me to
rewrite the completion code as native Bash functions, with as few external
calls a
On Mon, Jul 18, 2016 at 01:46:40PM +0200, Tobia Conforto wrote:
> Hello
>
> I would like to add a feature (and contribute the code, if anybody is
> interested): make the 'pct' bash completion show the hostnames when a vmid
> parameter is being completed.
This should probably be optional (perhap
Else we crash fatally on an existing but empty status file like
/etc/pve/manager_status , reproducible with:
$ > /etc/pve/ha/manager_status
We do not want to catch arbitrary errors as then users cannot
reconstruct what happened in the event of an error.
Signed-off-by: Thomas Lamprecht
---
chang
mostly copied from QemuServer
Signed-off-by: Dominik Csapak
---
src/PVE/CLI/pct.pm | 40
1 file changed, 40 insertions(+)
diff --git a/src/PVE/CLI/pct.pm b/src/PVE/CLI/pct.pm
index 3e99313..cf4a014 100755
--- a/src/PVE/CLI/pct.pm
+++ b/src/PVE/CLI/pct.pm
Hello
I would like to add a feature (and contribute the code, if anybody is
interested): make the 'pct' bash completion show the hostnames when a vmid
parameter is being completed.
Current behaviour:
# pct enter
200 201 202 ...
What I'd like to get:
# pct enter
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> > if (defined($conf) && $conf->{agent}) {
> > vm_qmp_command($vmid, { execute => "guest-shutdown" },
> > $nocheck);
> > } else {
> > vm_qmp_command($vmid, { execute => "system_powerdown" },
> > $nocheck);
> > }
> >
> What happ
In the event that the cluster remains stable from the HA view
point (i.e. no LRM failures, no service changes) and a service
with a start error relocate policy configured fails to start
it will cycle between two nodes back and forth, even if other
untried nodes (with a possibility that the service
factor out the default group generation and the priority group
generation.
Signed-off-by: Thomas Lamprecht
---
changes since v3:
* new in this version
src/PVE/HA/Manager.pm | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/PVE/HA/Manager.pm b/src/P
Instead of counting up an integer on each failed start trial, record
the already tried nodes. We can then use the size of the tried nodes
record array as 'try count' and achieve so the same behaviour as with
the 'relocate_trial' hash earlier.
Log the tried nodes after the service started or if it
Cleanup the manager state in a general way if we get promoted to
manager. This safes us code as instead of having to check all
deprecated entries and delete them, each one extra, we just safe the
state part needed to change master without loosing any result of the
manager status and just delete the
we did not check if some values were hash refs in
the verbose output.
this patch adds a recursive hash print sub and uses it
Signed-off-by: Dominik Csapak
---
PVE/CLI/qm.pm | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/PVE/CLI/qm.pm b/PVE/CLI
On Mon, 18 Jul 2016 06:15:13 +0200 (CEST)
Dietmar Maurer wrote:
>
> yes
>
> if (defined($conf) && $conf->{agent}) {
> vm_qmp_command($vmid, { execute => "guest-shutdown" },
> $nocheck);
> } else {
> vm_qmp_command($vmid, { execute
It is also used for backups (e.g. filesystem freeze) which is very handy
for hook-scripts.
One thing I couldn't find is how long the timeout for the agent to respond
is. If some hook-scripts take too long, I get timeouts while backing up.
Would be great to know the limit and maybe increase it.
Fo
instead of having "Do not use a proxy" simply
use PVE.Utils.noneText, which defaults to 'none'
Signed-off-by: Dominik Csapak
---
www/manager6/dc/OptionView.js | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/www/manager6/dc/OptionView.js b/www/manager6/dc/OptionView.js
i
26 matches
Mail list logo
