Comment 1 Henrik Andersson 2018-05-24 10:40:39 CEST

A simple idea is to introduce grouping of agents in vsmserver which are mapped to users / groups, and let the loadbalancer do the magic of choosing which agent to create a new session on.

Current configuration of cluster looks like this:

 [/vsmserver]
 terminalservers = 127.0.0.1

and it could be changed into this:

 [/vsmserver/subcluster/Default]
 terminalservers = 127.0.0.1
 groups =

and if an administrator wants to add a subcluster (group of agents) for devs it could look like this:

 [/vsmserver/subcluster/Devs]
 terminalservers = 127.0.0.2
 groups = Developers

Comment 2 Henrik Andersson 2018-05-24 10:53:47 CEST

Acceptance criteria:

- Administrator should be able to associate users and/or groups to a subcluster in order for the ThinLinc server to automatically select which agent to start new sessions on.

- Seamless migration of /vsmserver/terminalservers when upgrading from an older version of the ThinLinc server.

- Documentation should be written in TAG and hinting comments in configuration file. TAG documentation should describe new configuration parameters and new concepts.

- Automatic unit and integration tests should be added to cover the changes.

- Change of configuration should be added to specific section in release notes.

- Web Administration UI should reflect the changes.

Comment 3 Henrik Andersson 2018-05-24 12:32:52 CEST

Acceptance criteria:

- Error handling with message to the end user when user is not associated with a subcluster (user or group) and there is no Default subcluster configured.

This is a good idea, but i think it is better to let the user choose which subcluster to join. Like https://www.cendio.com/bugzilla/show_bug.cgi?id=5362 ...

But still a very good idea.

Comment 5 Samuel Mannehed 2018-05-25 12:30:43 CEST

(In reply to comment #4)
> This is a good idea, but i think it is better to let the user choose which
> subcluster to join. Like https://www.cendio.com/bugzilla/show_bug.cgi?id=5362
> ...
> 
> But still a very good idea.

Peter, you can view this as a first step in that direction. This server-side implementation can be expanded upon and adding a user-choice is a smaller step once this is in place.

Comment 6 Samuel Mannehed 2018-05-28 10:07:05 CEST

This change means moving /vsmserver/terminalservers to /vsmserver/subcluster/<name>/terminalservers. We will also rename the parameter terminalservers to agents:


  /vsmserver/subcluster/<name>/agents

Comment 7 Samuel Mannehed 2018-05-28 10:11:52 CEST

(In reply to comment #0)

> Today customers are using the explicit_agentselection for this case but does
> not get loadbalancing.
>

We have decided to remove explicit_agentselection and an upgrade should migrate the current explicit_agentselection configuration into subcluster structure.

Comment 8 Samuel Mannehed 2018-05-28 10:15:24 CEST

Acceptance criteria:

 - upgrade should migrate the current explicit_agentselection configuration into subcluster structure

Comment 17 Samuel Mannehed 2018-06-01 16:49:15 CEST

That should be all:

* Subcluster implementation
* Automatic tests
* Documentation
* Web Admin GUI
* Updated tl-rsync-all and tl-ssh-all
* Removed explicit_agentselection
* Renamed terminalservers to agents
* Seamless migration possible through tl-setup (see bug 7193)
* Release notes

(In reply to comment #5)
> (In reply to comment #4)
> > This is a good idea, but i think it is better to let the user choose which
> > subcluster to join. Like https://www.cendio.com/bugzilla/show_bug.cgi?id=5362
> > ...
> > 
> > But still a very good idea.
> 
> Peter, you can view this as a first step in that direction. This server-side
> implementation can be expanded upon and adding a user-choice is a smaller step
> once this is in place.

So what happens if a user have access to multiple subclusters? There is no way to choose....

Comment 19 Samuel Mannehed 2018-06-02 23:59:58 CEST

(In reply to comment #18)
> 
> So what happens if a user have access to multiple subclusters? There is no way
> to choose....

Subclusters will be limited to admin configuration for now.

If a user is associated with multiple clusters the system has been configured incorrectly. In this case the user will automatically end up on one of the subclusters and a warning will be logged for the admin.

Comment 21 Samuel Mannehed 2018-06-04 09:26:35 CEST

One of the integration tests fail, reopening.

Comment 24 Samuel Mannehed 2018-06-04 13:58:54 CEST

(In reply to comment #21)
> One of the integration tests fail, reopening.

Found and fixed a couple of typos in the tests.

Comment 26 Pierre Ossman 2018-06-08 14:23:34 CEST

Started testing, and mostly works fine, but two bugs found so far:

a) User matching is doing using username, not uid, so it will not handle aliases properly (e.g. case insensitive systems).

b) You get a warning about a user qualifying for multiple subclusters via their groups even if the user is listed explicitly as a user. I.e.

[/vsmserver/subclusters/A]
users=userA
groups=group1withA

[/vsmserver/subclusters/B]
users=
groups=group2withA

There is no ambiguity here, so the system shouldn't warn.

Comment 28 Pierre Ossman 2018-06-11 14:42:04 CEST

There is a check to warn the admin if an agent is defined in multiple sub clusters. Unfortunately it easily misses things right now.

The check triggers when a new session is created, and it only checks the first ("best") agent. If that agent fails to create a session then the rest do not get the sanity check.

Perhaps we should do the sanity check on startup so that everything is checked all at once? It would also mean getting an early warning for the admin.

Comment 29 Pierre Ossman 2018-06-11 14:45:15 CEST

The new images for the documentation aren't packaged properly.

Comment 31 Henrik Andersson 2018-06-11 15:10:09 CEST

(In reply to comment #26)
> Started testing, and mostly works fine, but two bugs found so far:
> 
> a) User matching is doing using username, not uid, so it will not handle
> aliases properly (e.g. case insensitive systems).
>

Commit r33401 solves this issue

> b) You get a warning about a user qualifying for multiple subclusters via their
> groups even if the user is listed explicitly as a user. I.e.
> 
> [/vsmserver/subclusters/A]
> users=userA
> groups=group1withA
> 
> [/vsmserver/subclusters/B]
> users=
> groups=group2withA
> 
> There is no ambiguity here, so the system shouldn't warn.

Commit r33402 solves this issue

Comment 33 Henrik Andersson 2018-06-11 16:22:57 CEST

(In reply to comment #29)
> The new images for the documentation aren't packaged properly.

Comment 35 Henrik Andersson 2018-06-11 16:30:40 CEST

(In reply to comment #33)
> (In reply to comment #29)
> > The new images for the documentation aren't packaged properly.

Fixed in commit r33404

Comment 36 Pierre Ossman 2018-06-12 11:02:05 CEST

(In reply to comment #31)
> (In reply to comment #26)
> > Started testing, and mostly works fine, but two bugs found so far:
> > 
> > a) User matching is doing using username, not uid, so it will not handle
> > aliases properly (e.g. case insensitive systems).
> >
> 
> Commit r33401 solves this issue
> 

Works well now.

> > b) You get a warning about a user qualifying for multiple subclusters via their
> > groups even if the user is listed explicitly as a user. I.e.
> > 
> 
> Commit r33402 solves this issue

Also works well.

(In reply to comment #35)
> (In reply to comment #33)
> > (In reply to comment #29)
> > > The new images for the documentation aren't packaged properly.
> 
> Fixed in commit r33404

Looks fine now.

(In reply to comment #28)
> There is a check to warn the admin if an agent is defined in multiple sub
> clusters. Unfortunately it easily misses things right now.
> 

It now nicely warns about duplication of agents, users and groups.

Comment 37 Pierre Ossman 2018-06-12 11:05:12 CEST

> * Administrator should be able to associate users and/or groups to a subcluster in order for the ThinLinc server to automatically select which agent to start new sessions on.
> 

✓ Tested various combinations of users and groups (including conflicting ones)

> * Documentation should be written in TAG and hinting comments in configuration file. TAG documentation should describe new configuration parameters and new concepts.
> 

✓ Seems easy enough to grasp. Related topics also updated AFAICT.

> * Automatic unit and integration tests should be added to cover the changes.
> 

✓ Seem to cover the essentials

> * Error handling with message to the end user when user is not associated with a subcluster (user or group) and there is no Default subcluster configured.
> 

✓ User gets a "no available agents" message

> * Seamless migration of /vsmserver/terminalservers to subcluster agents when upgrading ThinLinc
> 

✓ Correctly moved to Default cluster

> * Seamless migration of /vsmserver/explicit_agentselection into subcluster structure when upgrading ThinLinc
> 

✓ Correctly moved to new subclusters, and merged when possible

> * Web Administration UI should reflect the changes
> 

✓ Works well. I was able to configure everything using the web ui.

> * Change of configuration should be added to specific section in release notes

✓ Looks good.

Comment 40 Pierre Ossman 2018-06-13 10:46:56 CEST

We aren't handling unicode usernames (and probably groups) properly.

Comment 43 Samuel Mannehed 2018-06-15 10:15:16 CEST

Verified that subclusters work well with unicode usernames now.