Skip to content
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.

TANGO_HOST multi db server #929

Open
reszelaz opened this issue Jun 20, 2019 · 4 comments · May be fixed by #938
Open

TANGO_HOST multi db server #929

reszelaz opened this issue Jun 20, 2019 · 4 comments · May be fixed by #938
Labels
enhancement

Comments

@reszelaz
Copy link

From sardana created by taurel: sardana-org/sardana#1151

At the ESRF machine side, our control system is configured with two running Tango database
servers. Therefore, the TANGO_HOST environment variable is set to host:port1,host:port2
(This is a relatively unknown but old Tango feature). We are now using sardana 2.7.0 with taurus 4.5.1.
The MacroServer refuses to start with such a TANGO_HOST env. variable with error message:

python MacroServer.py ebs_psMainThread WARNING 2019-06-19 14:47:20,878 TaurusRootLogger: /operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/sardana/pool/pooldefs.py:34: DeprecationWarning: taurus.external.enum is deprecated since 4.3.2. Use enum (enum34 module) instead
from taurus.external.enum import IntEnum

MainThread CRITICAL 2019-06-19 14:47:21,275 TaurusRootLogger: Server exited with DevFailed
Traceback (most recent call last):
File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/sardana/tango/core/util.py", line 1175, in run_tango_server
util.server_init()
DevFailed: DevFailed[
DevError[
desc = TypeError: 'NoneType' object is not iterable

origin = File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/tango/device_class.py", line 571, in __DeviceClass__device_factory
device = self._new_device(deviceImplClass, klass, dev_name)
File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/tango/device_class.py", line 550, in __DeviceClass__new_device
return klass(dev_class, dev_name)
File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/sardana/tango/macroserver/MacroServer.py", line 51, in init
SardanaDevice.init(self, cl, name)
File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/sardana/tango/core/SardanaDevice.py", line 78, in init
self.init(name)
File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/sardana/tango/macroserver/MacroServer.py", line 59, in init
self._macro_server = ms = MS(self.get_full_name(), self.alias)
File "/operation/common/miniconda3/envs/py27/lib/python2.7/site-packages/sardana/tango/core/SardanaDevice.py", line 150, in get_full_name
db_name, _, _ = TangoAuthorityNameValidator().getNames(db_name)

reason = PyDs_PythonError
severity = ERR]
]

As printed by the stacktrace, the problem is around line 150 of sardana/tango/core/SardanaDevice.py (method get_full_name) where the value of the TANGO_HOST is used
to build a device name FQDN.

There is a simple workaround which is to reset the TANGO_HOST env. variable to its
simple form

Cheers and good luck
@reszelaz reszelaz mentioned this issue Jun 20, 2019
Closed
@reszelaz
Copy link
Author

This issue was originally reported by @taurel. I move it to Taurus since the affected code proceeds from this project.

@cpascual
Copy link
Member

cpascual commented Jun 21, 2019 •
edited
Loading

There is a simple workaround which is to reset the TANGO_HOST env. variable to its
simple form

Sorry if this is too obvious, but I just want to note that one does not need to globally change the system environment variable, but it suffices to change it for the macroserver execution... and therefore it may be convenient to set a bash alias for the macroserver launcher more or less as:

alias MacroServer='TANGO_HOST=`echo $TANGO_HOST|cut -d, -f1` MacroServer'

This is not meant as a solution, just as a more "automatic" form of the workaround...

@cmft
Copy link
Member

cmft commented Jun 21, 2019

We checked that if the first TANGO_HOST does not exist PyTango will connect to the second one. But the names

In [1]: import tango
In [2]: db =tango.Database()
In [4]: db.get_db_host()
Out[4]: 'foo'
In [5]: db.get_db_port()
Out[5]: '10000'

@cpascual
Copy link
Member

After some internal discussions, we see three different approaches to support this:

  • a) make taurus select one of the hosts and use it from then on
  • b) accept the comma-separated list of hosts as a valid Tango authority (strictly speaking we would need to percent-encode the : to be RFC3986-compliant in our URIs) and delegate the handling to PyTango
  • c) reserving a name for an special type of authority in the taurus tango scheme (e.g. ".dynamic_auth.") which would indicate taurus that the authority is to be resolved dynamically by PyTango

Approach a) has the advantage that everything would probably work as-is in Taurus, but has the problem that the URI, if stored, would fix one of the tango DBs, efectively disabling the multi-host feature of tango.

Approach b) is likely to require more changes in taurus, since it is likely that more parts of taurus assume single host as the authority.

Approach c) may need some work but could be quite neat since it would also be useful to solve another use-case: Taurus Guis which should work under different hosts.

cmft added a commit to cmft/taurus that referenced this issue Jul 1, 2019
@cmft
Support TANGO_HOST multi db server
a1e97cb 
TangoValidators do not support URIs with multiples db.
A Tango system can be configured with two running
Tango databases. The TANGO_HOST environment variable for that cases
is set to host:port1,host:port2...

Support Tango multi db URIs using a reserved work `.dynamic_auth.`
to indicate taurus that the authority is to be resolved dynamically
by PyTango.

Fix taurus-org#929
@cmft cmft linked a pull request Jul 1, 2019 that will close this issue
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Implement "dynamic_auth" for Tango cmft/taurus
3 participants
@cpascual @cmft @reszelaz