Bug 571 - vsm* names are confusing and inconsistent
Summary: vsm* names are confusing and inconsistent
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.3.0
Hardware: PC Linux
: P2 Enhancement
Target Milestone: MediumPrio
Assignee: Peter Åstrand
URL:
Keywords:
: 60 (view as bug list)
Depends on: 5066 5532 5534 5801
Blocks: 4717
  Show dependency treegraph
 
Reported: 2004-05-14 12:55 CEST by Peter Åstrand
Modified: 2023-11-30 14:16 CET (History)
3 users (show)

See Also:
Acceptance Criteria:
MUST: * Our names should clearly indicate that things belong to ThinLinc, when they appear in a context that isn't obviously ThinLinc-related: * Our services should not have "vsm" in their names. * Logfile names should not contain "vsm". SHOULD: * Outwards facing names and information shouldn't mention VSM: * Our documentation shouldn't mention VSM. * The Web Admin menu should not contain "VSM". * Names of configuration variables should not contain "vsm" COULD: * Our internal names and texts, like code, shouldn't mention "vsm".


Attachments

Description Peter Åstrand cendio 2004-05-14 12:55:03 CEST
"VNC Session Manager" is not perhaps a very good name, since VSM does more than
keeps track of VNC. Perhaps VSM should be renamed to "ThinLinc Session Manager":
TSM or TLSM.
Comment 1 Peter Åstrand cendio 2005-01-18 14:47:01 CET
Another idea from Roke and Daniel is that we keep VSM, but change the meaning of
the V: It could mean "Virtual" or something like that, instead of VNC. 
Comment 2 Peter Åstrand cendio 2005-02-10 09:50:54 CET
Another suggestion from Roke: Versatile Session Manager. 
Comment 3 Erik Forsberg cendio 2005-02-10 10:00:59 CET
I still think Peters suggestion - "VSM Session Manager" is the best one so far :-).
Comment 4 Pierre Ossman cendio 2012-01-23 13:30:40 CET
These days we've started using the terminology master/agent. We should get rid of all the vsm references in favour of these as the old naming is just confusing to new users.

The term "server" might be allowed in certain end-user places as that is the term they expect when comparing with similar products. The master/agent distinction is something only the administrators should have to know about.
Comment 5 Pierre Ossman cendio 2013-08-13 15:23:45 CEST
Might also want to purge ctc references at the same time.
Comment 6 Karl Mikaelsson cendio 2014-01-17 12:32:00 CET
If we're moving log files around, consider bug 4961.
Comment 7 Peter Åstrand cendio 2015-08-25 09:37:41 CEST
A "grep" for vsm in the ctc tree gives 1500 matches, so this might take some time.
Comment 8 Peter Åstrand cendio 2016-01-18 14:15:00 CET
(In reply to comment #7)
> A "grep" for vsm in the ctc tree gives 1500 matches, so this might take some
> time.

A new search gives 1243 matches, after filtering out things such as the auto tests. 

There are several challenges to solve this bug:

1) Decide on new names. The general idea of replacing "VSM Server" with "Master" and "VSM Agent" with "Agent" is probably good. But as always, the devil is in the details. If you consider, for example, /var/log/vsmserver.log, there are many possible alternativs:

/var/log/master.log
/var/log/tlmaster.log
/var/log/tl-master.log
/var/log/thinlinc-master.log
/var/log/server.log
/var/log/tlserver.log
/var/log/tl-server.log
/var/log/thinlinc-server.log

master.log and server.log are poor names, though, but there are still many options. In general, we need to select between "master" and "server", multiplied with the prefixes "tl", "tl-", and "thinlinc". We are not consistent:

tlclient
tlsnd
tl-setup
thinlinc-login

/var/log/thinlinc-install.log
/var/log/tlclient.cgi.log
/var/log/tlsetup.log
/var/log/tlwebaccess.log
/var/log/tlwebadm.log

IMHO, I think we should avoid the "thinlinc-" prefix, since that's the least used variant. Selecting between "tl" and "tl-" is more difficult since "tl" is the most common log file prefix, while "tl-" is more common for binaries etc. The web administration service is called "tlwebadm", and has a matching log file, but the setup program is called "tl-setup" and the log file is called "tlsetup.log". But since it's probably not a good idea to have a dash in a service name, and to follow the earlier services, I think we should go for:

/var/log/tlmaster.log

(Still thinks we should rename tlsetup.log to tl-setup.log though.)

As comment #6 says, we could consider bug 4961. IMHO, this should not affect the file names though. 




2) Should we only change all user/admin visible parts, or even internal things such as variable names? I think we should change even internal things,
to avoid confusion and also make it easier to search for missed "vsm" strings. 



3) Configuration issues. On the positive side, "vsm" is only used in a few places in the configuration name space:

vsm/ 
    vsm_server_port = 9000
    vsm_agent_port = 904

vsmagent/
    logging/
        logfile = /var/log/vsmagent.log
        levels/ 
            vsmagent.extcmd = INFO
            vsmagent.xmlrpc = INFO
            vsmagent.session = INFO

(plus corresponding stuff for vsmserver)

One problem is the /vsm folder, which is common for both the master and agent. There's no obvious new name for this folder. Perhaps "tl"? From a machine wide Hiveconf perspective, we would get a folder called /thinlinc/tl, but that's no big issue. "tl" would match "tlmaster" and "tlagent" service names. Another idea would be "server". That would better match the package name suggestion (see below). 

Then we also have "vsm" in the configuration file names. Even if there are only a handful places, the fact that the service "top" folders have "vsm" in the name means that all VSM configuration parameters are possibly affected by a name change. Our options are:

1) Do nothing - keep the old names. But that is no "solution" according to this bug description 

2) Rename. No special handling - let the administrators deal with the name change. 

3) Rename. Introduce code that helps with the name changes. 

For the latter approach, we could in principle automatically rename .rpmsave files into their new name, and also replace "vsm" strings in them. This could be done before the new config migrate dialog, to make sure all 3 options in that dialog works. But the question is, should we do this kind of replacement, and should it be automatic and silent? 



4) Package name. We have a package called "thinlinc-vsm". If it should contain both services, we again need to find a new "common" word for the master and the agent. One idea is "thinlinc-server". 



To summarize: My conclusion is that getting rid of "vsm" is not easy or simple, but possible.
Comment 9 Samuel Mannehed cendio 2016-01-20 12:24:11 CET
I deem this sufficient to be a decision basis.
Comment 13 Peter Åstrand cendio 2016-02-29 14:17:52 CET
> 
> 3) Configuration issues. On the positive side, "vsm" is only used in a few
> places in the configuration name space:
...
 
> Even if there are only
> a handful places, the fact that the service "top" folders have "vsm" in the
> name means that all VSM configuration parameters are possibly affected by a
> name change. Our options are:
> 
> 1) Do nothing - keep the old names. But that is no "solution" according to this
> bug description 
> 
> 2) Rename. No special handling - let the administrators deal with the name
> change. 
> 
> 3) Rename. Introduce code that helps with the name changes. 

Note that for option 3), there are multiple solutions:

3a) Replace strings in our config files. This could be easily done in the config migrate step in tl-setup, since we only need to do this for "conflicting files"; only if the admin has actually done some changes that needs to be preserved. I have a patch that is ~60 lines that does this. The drawback is that we are not processing custom config files, such as "alocal.hconf" or /usr/share/example.com/global.hconf. 

3b) Extend the Hiveconf API with a "rename" operation. This would allow us to change the names in other config files as well. Note that this will still not be a 100% solution, since it's possible to have hconf files which "masks" parameters in other hconf files (say, local.hconf overriding /usr/share/example.com/global.hconf). Besides, /usr/share/example.com/global.hconf could be on a read-only file system.
Comment 14 Peter Åstrand cendio 2016-02-29 14:20:40 CET
(In reply to comment #13)

> 3a) Replace strings in our config files. This could be easily done in the
> config migrate step in tl-setup, since we only need to do this for "conflicting
> files"; only if the admin has actually done some changes that needs to be
> preserved. I have a patch that is ~60 lines that does this. The drawback is
> that we are not processing custom config files, such as "alocal.hconf" or
> /usr/share/example.com/global.hconf. 
> 
> 3b) Extend the Hiveconf API with a "rename" operation. This would allow us to
> change the names in other config files as well. Note that this will still not
> be a 100% solution, since it's possible to have hconf files which "masks"
> parameters in other hconf files (say, local.hconf overriding
> /usr/share/example.com/global.hconf). Besides,
> /usr/share/example.com/global.hconf could be on a read-only file system.

An additional solution would be to basically use 3a), but do the search-and-replace in all files in /opt/thinlinc/etc/conf.d. With the examples above, this would correctly
handle "alocal.hconf" but not /usr/share/example.com/global.hconf.
Comment 27 Samuel Mannehed cendio 2016-03-07 14:36:18 CET
See bug 5066, related
Comment 32 Samuel Mannehed cendio 2016-03-16 16:24:17 CET
We have to remember to double check documentation images. We suspect that some PNG files have been edited directly instead of using the .dia-files.
Comment 33 Pierre Ossman cendio 2016-03-21 13:41:04 CET
A suggestion for file structure in vsm/ can be found here:

http://git.cendio.se/cgit/~ossman/thinlinc.git/log/?h=restructure

And a suggestion for packaging everything as simply thinlinc-server can be found here:

http://git.cendio.se/cgit/~ossman/thinlinc.git/log/?h=packaging2

(solves what to do with the thinlinc-vsm rpm/deb)
Comment 34 Karl Mikaelsson cendio 2016-10-07 16:26:54 CEST
*** Bug 60 has been marked as a duplicate of this bug. ***
Comment 36 Pierre Ossman cendio 2018-10-08 10:55:47 CEST
Bug 5532 is probably interesting as part of this. It might also help with some of the /vsm config entries.

Note You need to log in before you can comment on or make changes to this bug.