I would like that one redundant master can be used for several "sub clusters". A sub cluster is some kind of grouping, maybe by operating system or by project or other things (member of a specific group maybe?). This makes it easy to implement new services for the customer. An example can be when Ubuntu releases a new version, add a sub cluster to your master and point it to the new ubuntu server(s). No need to inform the users where the new master can be found. The next time the user starts a new session, the servers (sub cluster) are available from the menu. Every sub cluste should behave like your current implementation, ie load balancing and other things. The user selects which sub cluster he/she wants to connect to and you fix the rest. It could look like this. General Ubuntu 14.10 General Ubuntu 14.04 LTS General Slowlaris SPARC General Solaris intel General Windows desktop Project Silver Omega Projetc Essential Gamma In each of these sub clusters there can be one or more servers running the Thinlinc Agent. Other advantages: One place to manage the licenses. Related bug: 1981
I think this is a great idea ;-)
Bug #7188 implements support for sub clusters, eg. grouping agents and assign users and groups to those groups. If a user is assigned to several groups, the first matching subcluster is used.
Ideas: 1. Present a list of assigned subcluster to the user upon connect that he can select among for connection (create / reconnect sesssion) 2. Fast select of cluster via servername eg. project1@tl.cendio.se
(In reply to comment #6) > > 2. Fast select of cluster via servername eg. project1@tl.cendio.se > The reasoning behind this future are that if a user have access to three sub clusters (A,B and C), and he is normally working with in cluster A. We can give them the option to normally connect to the specific sub cluster A without presenting a list of available clusters for selection / interaction, cutting down on "interaction" during connect for the normal case.
(In reply to comment #6) > > 1. Present a list of assigned subcluster to the user upon connect that > he can select among for connection (create / reconnect sesssion) > There are several ways to do this and the following two ideas are in my thoughts: 1. During communication with master, query list of subcluster and present a dialog for the user to select which subcluster he wants to connect to. The dialog could look like: [ Select subcluster X ] Name Description ------------------------------------------------- Main Desktop This is the subcluster for normal desktop usage. Project NewBorn Subcluster for development server of project newborn [ Cancel ] [ Select ] After the selection of a subcluster the normal connect policy will take affect against the select subcluster as we currently know. 2. Make selection of subcluster a part of connection policy for example. This way we could merge the session management and subcluster selection into one mechanism and dialog. Examples: If a user have a only access to one subcluster and there is no session, a new session will be created without needing interactions for the enduser. If a user have a only access to one subcluster and there is a session, reconnect to session without needing interactions for the enduser. If user have access to more than one subcluster where he have a session on one of them, show the "Select session" for user action. The dialog could look something like: Main Desktop This is the subcluster for normal desktop usage Id Agent Resolution Created Status Command --------------------------------------------------------------------- 1 tlamain01 1280x1027 2018-11-30 Disconnected New Session... Project Newborn Subcluster for development server of project newborn Id Agent Resolution Created Status Command --------------------------------------------------------------------- New Session... [ End session ] [ Cancel ] [ Connect ]
(In reply to comment #14) > 2. Make selection of subcluster a part of connection policy for example. > This way we could merge the session management and subcluster selection > into one mechanism and dialog. In the future this could also be merged with the profile chooser perhaps.
See bug 300 for doing the profile choice before starting the session
