search

ControlSystemStudio / cs-studio

Control System Studio is an Eclipse-based collections of tools to monitor and operate large scale control systems, such as the ones in the accelerator community.
https://controlsystemstudio.org/
Eclipse Public License 1.0
111 stars 96 forks source link

Configuration directory #94

Closed gcarcassi closed 10 years ago

gcarcassi commented 10 years ago

I need a directory to store configuration data for services, and I'd like it to be a common mechanism.

The direct requirement is for JDBC services: I'd like people to add support for a service (which is a database location plus some queries) just by putting a file in a directory. This would allow users to plug in different services without requiring to program Java or to rebuild CS-Studio.

This would also useful for PVAccess services, so that services implementers can just drop an XML file in CS-Studio to start testing their service within BOY.

To do that, I need a directory where I can place the following directory structure: services jdbc service1.xml service2.xml pva pvaservice1.xml

For deployment, this is also nice because allows a site to layer that configuration on top of the product. Which helps the migration to a common product.

Now, where that directory should be? The strawman proposal is to simply use the config directory within the product itself. First it's already there. Second, if a site publishes CS-Studio in a read only directory, that configuration too will be read-only.

kasemir commented 10 years ago

The use of external configuration files seems good when the configuration is "complicated" (more than just a short string) and/or if there is already an existing file format. One example is the JAAS configuration. To use that in org.csstudio.security, there's an Eclipse preference to name the external JAAS config file, which can be truly external, or a file inside another plugin:

org.csstudio.security/jaas_config_file=platform:/plugin/org.csstudio.security/jaas.conf

If you have for example a plugin org.csstudio.pvmanager.jdbc that uses such external config files, you could do it in a similar way:

org.csstudio.pvmanager.jdbc/service_config_dir=/path/to/the/dir/that/has/config/files

The advantage of using Eclipse preferences (and the disadvantage of using external files): The eclipse preferences are hierarchical. A plugin can define preferences.ini, the product can override in plugin_customization.ini, the command line can provide a replacement -pluginCustomization /path/to/my/settings, and finally there's the preference GUI. That mechanism is common to all RCP apps. With external files, there's no 'default', 'override for site-specific product', 'user settings'.

The eclipse preferences up to the product's plugin_customization.ini are part of the product configuration. An online update or roll-back from an update site will install/uninstall those settings. When you simply drop an outside file into a magic directory location, that history is not tracked.

Eclipse preferences can be exported and imported. The exported prefs can be compared. With external files, it's harder to say: Email me your exported preferences so I can see what you're using.

kasemir commented 10 years ago

.. so org.csstudio.security supports both:

1) External JAAS config. There's an Eclipse preference to specify that file, it doesn't need to be in a magic location. -> The usual JAAS format, but detail not tracked in the Eclipse prefs.

2) Put the whole config into one preference org.csstudio.security/jaas_config=com.sun.security.auth.module.LdapLoginModule required debug="true" useSSL="false" userProvider="ldap://localhost:389/ou=Users,dc=css-demo,dc=org" authIdentity="uid={USERNAME},ou=Users,dc=css-demo,dc=org";

-> Trackable, you can import/export that as part of the overall eclipse preferences. But it sure gets ugly since you need to serialize/deserialize the whole config into one Eclipse preference string.

gcarcassi commented 10 years ago

The other question is: how does configuration of CS-Studio tie in with the rest of the configuration of EPICS clients.

Any of these pieces needs configuration:

And they are going to get accessed by CS-Studio, as well as other command line utilities and python scripts. A system administrator would like to hold one configuration for all, instead of separate configurations for each of them. This is also more important if the people managing these services are different.

The other problem is that some of these settings should be "locked", i.e. the user should not be able to change them. I am not sure how that can be achieved with the eclipse properties. With files, that can be enforced by permissions.

I guess there are multiple use cases here:

It's not clear to me how, but we need to find a reasonable way to satisfy them all...

gcarcassi commented 10 years ago

On the tech side: Platform.getInstallLocation() gives the location of the eclipse rcp. So, for now, I am using: File productDirectory = new File(Platform.getInstallLocation().getURL().getFile() + "/configuration/services/jdbc");

Platform.getInstanceLocation() gives the workspace directory.

berryma4 commented 10 years ago

Maybe I'm wrong ... but I don't see Olog or ChannelFinder needing more than what's in the preference file.

as for: "The other problem is that some of these settings should be "locked", i.e. the user should not be able to change them. I am not sure how that can be achieved with the eclipse properties. With files, that can be enforced by permissions."

How I do it, "css-frib -pluginCustomization /etc/css/plugin_customization.ini" is what /usr/bin/css-frib executes. and puppet controls plugin_customization.ini

In windows, it just goes in the install directory ... I don't have configuration management for windows.

gcarcassi commented 10 years ago

Maybe I'm wrong ... but I don't see Olog or ChannelFinder needing more than what's in the preference file. Right. The point is that if I am writing a pyQt client that writes to Olog (not CS-Studio, like some users in NSLS2 physics group does) that too needs to be configured. And you'd like to manage the configuration in one place.

Same thing with CAJ: there are the Java clients, the C clients, the python clients, etc...

So: it's whether we focus only on CS-Studio configuration, or we want to tie in for the rest of EPICS for the pieces that do exist (like CA client libs) and consider use of other libraries outside of CS-Studio or not.

puppet controls plugin_customization.ini Perfect. Now: if we make a common product, would that be how we handle user configuration?

mdavidsaver commented 10 years ago

How about a search path? Code asks for "file1.xml". There is a preference which defines a list of directories (colon separated or similar) which are searched and the first match is returned. Such a search could begin in the users home directory, proceed through system directories (/etc), and end in some product packaged default.

This is a common and well understood mechanism, which should be flexible enough to cover almost any deployment.

berryma4 commented 10 years ago

I agree with this ....

On Fri, Aug 2, 2013 at 6:38 PM, mdavidsaver notifications@github.comwrote:

How about a search path? Code asks for "file1.xml". There is a preference which defines a list of directories (colon separated or similar) which are searched and the first match is returned. Such a search could begin in the users home directory, proceed through system directories (/etc), and end in some product packaged default.

This is a common and well understood mechanism, which should be flexible enough to cover almost any deployment.

— Reply to this email directly or view it on GitHubhttps://github.com/ControlSystemStudio/cs-studio/issues/94#issuecomment-22040846 .

gcarcassi commented 10 years ago

For Eclipse properties there is a search path in terms of defaults/product/workspace. I don't know the fine details (i.e. whether I can cannibalize that to store other files). I think we need a full prototype to understand that (anybody knows already?). The workspace is also the area where "project" files are stored. I never know whether that's good or bad.

For search path, things may need to be "merged". For example, I need a directory where each file is a service. If I support a search path, than I need all the files from all the directories found in the search path. First file wins.

gcarcassi commented 10 years ago

Moving to 3.2.10 I think we have agreed on a search path. We haven't figured out the technical details of how to do that (mainly interaction with Eclipse properties).

gcarcassi commented 10 years ago

Moving to 3.2.11 No progress on this.

berryma4 commented 10 years ago

Can we agree these are the cases we would like to solve, are there others? If so, let's write what we are doing for each case:

berryma4 commented 10 years ago

This should be changed to 3.3.x.