Bug 2433 - Store configuration metadata in Hiveconf
Summary: Store configuration metadata in Hiveconf
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 Enhancement
Target Milestone: LowPrio
Assignee: Peter Åstrand
Depends on:
Blocks: 4650 5851
  Show dependency treegraph
Reported: 2007-03-27 15:02 CEST by Erik Forsberg
Modified: 2017-01-10 11:31 CET (History)
0 users

See Also:
Acceptance Criteria:


Description Erik Forsberg cendio 2007-03-27 15:02:22 CEST
Each configuration parameter in hiveconf has several pieces of information:

* The current value - this is currently set in the .hconf files.

* The default value - this is currently set in our code, where it's
  not available neither to system administrators that want to know if
  the setting has been changed, nor to other tools that want to know
  the default value (web-based administration tools, etc.). It would
  also be nice to be able to auto-generate documentation with the
  default value listed, and that is currently not possible without
  parsing the python code..

* Documentation - this is currently, if the developer remembers to do
  it, available in TAG. There are also comments in the .hconf. There's
  no guarantee that the comments in .hconf files correspond to the
  documentation in TAG. As with the default value, it would be nice to
  write the documentation in one place, and then auto-generate
  configuration information to be placed in the TAG. 

* Allowed values/type of parameter - this is currently, in some cases,
  documented in comments in the .hconf and in the TAG.

  For a web-based administration tool to work well, it would need to
  now if the value is a string, a string list, an integer, etc. It
  would also need to know if a string value has a limited set of
  values (example: /appservergroups/rdp/<group>/sound), if an integer
  value has a limit on the range, etc. 

  This information would also be interesting to list in the TAG. 

Regarding the default values, the policy until now has been that they
should remain in source code to make sure ThinLinc runs without
configuration files available. Currently it doesn't work, btw -
vsmserver and vsmagent starts, but vsmagent fails when trying to
create a session.

In my opinion, it would be better if the default values were available
to system administrators and documentation generation systems. Being
able to run ThinLinc without configuration files to me sounds like a
corner case we don't need to support. 

So, what's the best way to implement this? I can see several

* Documentation should be available near each parameter (in
  the .hconf files). It should be easy for the administrator to edit
  the .hconf files, which means some documentation for each parameter
  need to be available in the .hconf.

* It's not neccesary to list all documentation for a parameter in the
  same .hconf as the parameter - that might make it hard to navigate
  due to the large files that will be the result. We do however need
  to ship the full documentation for all parameters in
  machine-parseable form to make it available to web-based
  configuration interfaces.

* Default value should be available near each parameter, to make it
  easy for the administrator to see if the parameter has been

* Default value should be machine-parseable for use in web-based
  configuration interfaces. 

* Allowed values should be available near each parameter, to make it
  easy for the administrator to edit the file. 

* Allowed values should be machine-parseable for use in web-based
  configuration interfaces.

The most tricky parts are probably how to represent allowed values in
a way that is both understandable for users, and machine-parsable.

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