Feature #2515: Component annotations - vdemo - Open Source Collaboration Platform

Feature #2515

Component annotations

Added by J. Moringen over 8 years ago. Updated almost 8 years ago.

Status:

Closed

Start date:

03/09/2016

Priority:

Normal

Due date:

Assignee:

% Done:

Category:

Target version:

Description

Is it possible to add "user defined" annotations to components? In particular, we would like to annotate components with information about their middleware configuration (e.g. "ROS with master such and such", "RSB with spread://dsc:4814", "no middleware").

History

#1 Updated by R. Haschke about 8 years ago

Where / how this annotations should be used then? Displayed in tk?

#2 Updated by R. Haschke about 8 years ago

I could realize some tooltips popping up after a while. Which widget should they associated with?
Content of the tooltip could be specified in VDEMO_components using some new option...

#3 Updated by R. Haschke about 8 years ago

Status changed from New to Feedback
Assignee set to J. Moringen

#4 Updated by J. Moringen about 8 years ago

Assignee deleted (~~J. Moringen~~)

R. Haschke wrote:

I could realize some tooltips popping up after a while. Which widget should they associated with?
Content of the tooltip could be specified in VDEMO_components using some new option...

That is not what I had in mind. Sorry that the intention was not clear from the description.

The use-case is as follows: For the CSRA system, there is a script that examines running processes for configured vdemo components to detect crashed components and generate a report like the following:

Checking 150 components
The following components are NOT running (20):
  spreaddaemon_AUD                on dsc
    «details not available»
  rsb_recordserver                on ayq
    │  <INFO> [15:36:33] [main thread] rsb.introspection variables.lisp
    │ (unregister-participant) -
    │ …
  auto-record                     on bvb
    «details not available»
  openhab_device-manager          on dsc
    «details not available»
  openhab_config-generator        on dsc
    «details not available»
  openhab_runtime                 on dsc
    «details not available»
  screenservice                   on gig
    «details not available»
  rsb_host_monitor                on ayq
    │ + initial_VDEMO_pid=60471
    │ + echo '[VDEMO_LOGROTATE] entering logrotation loop
    │ …
  rsb_host_monitor                on syd
    │ + true
    │ + ps -p 14611
    │ …
  rsb_host_monitor                on lol
    «details not available»
  rsb_host_monitor                on sur
    «details not available»
  jack                            on dsc
    «details not available»
  Hookah                          on dsc
    «details not available»
  JackWatchdog                    on dsc
    «details not available»
  Batcry                          on dsc
    «details not available»
  Radio                           on dsc
    «details not available»
  tabletcam                       on mia
    «details not available»
  faceid_socket_server            on dsc
    «details not available»
  hlc_srv_kitchen                 on apw
    «details not available»
  floor_base_sports               on mel
    «details not available»
The following components are running (130):
  proximity_categories            on dsc
  transform_robot_data            on dsc
  rsb_bridge_robot                on dsc
  taskproxy                       on dsc
  jenkins-connector               on ayq
  …

This is done by parsing the vdemo configuration and executing pieces of shell code like the following (this is the origin of #2514)

ssh csracontrol@dsc 'bash -c \'source /vol/csra/releases/trusty/lsp-csra-nightly/lib/vdemo/vdemo_base.sh > /dev/null && source /vol/csra/releases/trusty/lsp-csra-nightly/etc/vdemo_scripts/lsp-csra-config.sh > /dev/null && vdemo_pidFromScreen openhab\''

I have implemented an extended check that can in principle test middleware connectivity. The problem is that such a check needs to know if and how the middleware connection of a given component works. The easiest solution I could think of was annotating components with a "middleware URL" or similar.

A new vdemo component option sounds like a good fit.

#5 Updated by R. Haschke about 8 years ago

Hi Jan,

Simply calling vdemo_pidFromScreen with the "short" name doesn't work.
You need to pass the "fully-qualified" component name, which is computed from
- the component's filename (without component_ prefix)
- "."
- the title of the component (which defaults to the filename too, but may be changed with option -t)

This name is computed in file vdemo_standard_component_suffix.sh.
The screen name has an underscore ("_") added to this name.

If you simply want to know the PID of the component's screen, you could directly run

screen -ls | grep "<component's screen name>\s" | cut -f1 -d.

In order to retrieve meta-information from the component, I suggest to add a function in the component script, which echos this information. Have a look at "inspect" for an example.

#6 Updated by J. Moringen almost 8 years ago

Status changed from Feedback to Closed

I still have to solve this, but if it can be done via a "user extension", this issue is no longer necessary.

#7 Updated by J. Moringen almost 8 years ago

And thanks for the suggestion.

Also available in: Atom PDF

vdemo

Issues