X2Go Bug report logs - #684
add exclude-hosts parameter to selectsession task

version graph

Package: python-x2gobroker; Maintainer for python-x2gobroker is (unknown); Source for python-x2gobroker is src:x2gobroker.

Reported by: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

Date: Tue, 2 Dec 2014 12:35:01 UTC

Severity: wishlist

Found in version 0.0.3.0-preview

Blocking fix for 690: request another server from broker provided server is down

Full log


🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#684: [X2Go-Dev] Bug#684: Bug#684: select_session offers offline servers to X2Go Client
Reply-To: Terje Andersen <teranders@gmail.com>, 684@bugs.x2go.org
Resent-From: Terje Andersen <teranders@gmail.com>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Mon, 08 Dec 2014 21:50:02 +0000
Resent-Message-ID: <handler.684.B684.141807532231319@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: followup 684
X-X2Go-PR-Package: python-x2gobroker
X-X2Go-PR-Keywords: 
Received: via spool by 684-submit@bugs.x2go.org id=B684.141807532231319
          (code B ref 684); Mon, 08 Dec 2014 21:50:02 +0000
Received: (at 684) by bugs.x2go.org; 8 Dec 2014 21:48:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
	HTML_MESSAGE,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham version=3.3.2
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 847865DB48
	for <684@bugs.x2go.org>; Mon,  8 Dec 2014 22:48:40 +0100 (CET)
Received: by mail-vc0-f172.google.com with SMTP id hq11so2628126vcb.17
        for <684@bugs.x2go.org>; Mon, 08 Dec 2014 13:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=l/N3hbIVKfBm2ieY7m4Y6YHpsczNyd+oXSjM7Krl59Y=;
        b=wLpHpS3B3vjNMZ5rhFbr8/9zms7g1gl2ruz5Aqu5I595B9I+U3F3ySIry9rNicTLO4
         DsVZI8bYCUlv2QocpOcI17JUYrR+DGz8XdVZszkAJpBFD2WCf2mHKBhhtITVdIPCY7hU
         xoPfCmQHIsiAEBpR4VwYjyiVloqU9i8uI01uDTPUAUcvoLq5EdhxP/3YdLZQF3CW/bAW
         2DjTC4C67zW7ZaDZjsKSHL1uMzEeyrKp5Ne7AzSym5SxMhb2nRf+RCiXobIR6BrLiXr3
         VfzxlGmT/rFKqMo4+r+J4E8lDcBGgQxoFITZx9c4FNr7wNtg/7l8HqXUZdhZaM/N5h7N
         oxNQ==
MIME-Version: 1.0
X-Received: by 10.52.65.227 with SMTP id a3mr22509133vdt.32.1418075318852;
 Mon, 08 Dec 2014 13:48:38 -0800 (PST)
Received: by 10.31.190.74 with HTTP; Mon, 8 Dec 2014 13:48:38 -0800 (PST)
In-Reply-To: <914829209.13176.1418043985279.JavaMail.zimbra@tophouse.ru>
References: <143861477.96320.1417796055431.JavaMail.zimbra@tophouse.ru>
	<1123477056.96337.1417796091693.JavaMail.zimbra@tophouse.ru>
	<20141206225605.Horde.h0QDOmvCPLZG5RzMvTt6XA3@mail.das-netzwerkteam.de>
	<92856184.99387.1417909528212.JavaMail.zimbra@tophouse.ru>
	<20141208072339.Horde.F4FcRmDw_W389jc-Roz0BA6@mail.das-netzwerkteam.de>
	<914829209.13176.1418043985279.JavaMail.zimbra@tophouse.ru>
Date: Mon, 8 Dec 2014 22:48:38 +0100
Message-ID: <CA+xgCO+18L8Z4ySN2Kk+2T9MfXpyXHGrxtB_f1z2p0m6uUE+hQ@mail.gmail.com>
From: Terje Andersen <teranders@gmail.com>
To: Sergey Savko <savko@tophouse.ru>, 684@bugs.x2go.org
Content-Type: multipart/alternative; boundary=20cf307f337aa521fe0509bb63aa
[Message part 1 (text/plain, inline)]
Why not introduce a datastore which holds the current state of all the
servers in the server farm? Then the broker could query that one for
information to choose server from.
One could either use a separate database server for this or use something
like sqlite (or mysql / postgresql / other) on each server host with some
sort of replication (redundancy and avoids the need to contact one specific
server - all can reply to the queries) or caching of the central datastore
contents.

On how to update this information in the datastore there's two ways I'm
thinking of right now:
1. Each server in the server farm writes to the datastore it's current
status at regular intervals
2. One, or several (backup role if the "master" should fail) server(s) have
been given the responsibility to query the servers in the farm for their
status at regular intervals

Regardless of the chosen implementation from one of those solutions would
IMO:
* Make the broker-role easier to implement with regard to "advanced" setups
* Removes the wait for / time issue at connection, or selection, process -
just contact the datastore
* Makes it possible to write a simple and central management app/webapp
which one could administer the entire server farm
* other possibilites

Regards,
Terje


2014-12-08 14:06 GMT+01:00 Sergey Savko <savko@tophouse.ru>:

> If you make a x2goclient connection to each farm server, then time will be
> increased by seconds for such connection.
> And if the server farm consist of more then 2-3 servers, then connection
> time will increase strongly.
>
> ----- Исходное сообщение -----
> >Plus, I still think, that X2Go Client should request another machine,
> >if the provided server was offline and more than one server is
> >configured in the broker's session profile.
> _______________________________________________
> x2go-dev mailing list
> x2go-dev@lists.x2go.org
> http://lists.x2go.org/listinfo/x2go-dev
>
[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.


X2Go Developers <owner@bugs.x2go.org>. Last modified: Thu Mar 28 22:07:58 2024; Machine Name: ymir.das-netzwerkteam.de

X2Go Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.