Some sr3/sr3d actions don't make sense on a cluster

[reidsunderland]

While working on #1 I realized that some of the possible actions for sr3 don't make sense on a cluster.

sr3d currently doesn't do any kind of filtering. Maybe it should?

• edit: if this were to do anything, it should edit the local copy of the config (and maybe sr3_commit it). But it shouldn't run on the remote nodes.
• add
• remove: maybe this should alias to sr3_remove? sr3_remove currently only supports one config at a time
• convert
• foreground
• run

[petersilva]

yeah, that sounds great. It would be great if those things were adapted so that they worked as they should but in the current cluster's tree (everything but cleanup/stop/start/restart/foreground)

I don't think there is a good way for foreground to work.

sr3d edit poll/hoho

should edit poll/hoho instead of ~/.config/sr3/poll/hoho. as you described... and yeah, maybe commit also.

weird ones:

show

show... again could just list them... like a normal invocation, but might be nicer to have something that runs the command on all nodes and then makes some kind of global report.

status   

for status ( MetPX/sarracenia#654 ) mentions that it could issue sr3 dumps on all the nodes, and then build a sensible global report, instead of just firing off sr3 status on each node. I dunno.

[reidsunderland]

See #6 for sr3d remove. I also added information output for other unsupported commands.

[reidsunderland]

convert has been implemented

[petersilva]

I was thinking... It would be nice if show worked. I tried to set the variable ... XDG_CONFIG_HOME=root of the cluster config tree) ... then launch sr3 show... but it's re-directing ~/.config, and not ~/.config/sr3 ... so it doesn't quite do the right thing.
It might be fun to be able to offset the config tree for sr3 to read, so:

sr3 show subscribe/xx

will have the same result as doing the same thing on one of the the nodes... but would need to implement that offset in sr3.

[reidsunderland]

sr3d show ... does work, it runs on all the nodes. I like that behaviour, since you don't have to have sr3 installed on the system you are running sr3_tools on, and variables like hostname will be displayed correctly.

If someone modifies something locally and forgets to commit it, it would be misleading to show what is local.

[petersilva]

fwiw... the "convert" is fantastic... does exactly what an analyst will want.

I'm constantly typing "sr3 edit" only to be disappointed though... it would be a good step.
the sr3 convert spits out the path name, so it's not like it doesn't know...
I tried it with sr3r and got this:

di-configs% sr3r edit sarra/get_msc-dms-op_hurricane
Data Pump Name: ddsr-dev. DSH Machine List: /fs/isilon-eccc13/ssc/hpcdi/silvap/gitlab/sr3-dev-config/_dsh_config/ddsr-dev.list
ddsr-cmc-dev01: Error: no write permission for file "sarra/get_msc-dms-op_hurricane"
ddsr-cmc-dev02: Error: no write permission for file "sarra/get_msc-dms-op_hurricane"
di-configs%

oh well...