Re: Question on Dynamic Node Filtering

[David Petzel]

bump.. Anyone have any advice for a newb on this one?

On Thursday, May 23, 2013 6:57:34 PM UTC-4, David Petzel wrote:

Rundeck newb here, sorry if this is covered elsewhere, but I couldn't find it on in the docs, on google, or in this list. The "Rundeck by example" documentation is soooo close to what I'm doing, with the following variance. In that example its two processes for a single service, I'm looking to re-use a single process for many applications.

I've got a number of services, which all have common restart routine, for the sake of the discussion, lets just assume a simple "sudo /sbin/service foo restart". Now I want to setup workflows, 1 per service. This would allow someone to execute a "rolling restart" of any of those applications using a workflow dedicated for that service (as opposed to an input option).

So my thought was that I could have a single "restart service" job which would take the service name as an input option. This way I could use the same job in all 10 workflows, instead of duplicating and just changing the service name.

The part I'm hung up is how to set my node filter on that base job. I've figured out how to call the base job with the service name option (thanks to the great documentation). In my I feel like the base job should have any nodes defined in the filter (I'm fearful that someone might try to run the base job directly). So I was playing with the idea of taking a host name as input into the base job, and then the workflow step would pass both service name and node name to the base job. Then in the base job I had ${node.hostname} in the node filter.

That didn't go so well, it appears the node filter tried to match the literal string of "${node.hostname}" rather than resolving the variable. Am I going about this all wrong? Whats the best way to most re-usability out of a base job like this in which many workflows might want to execute it on various nodes.?

Thanks

[Greg Schueler]

Hi David,

You could use tags combined with the service name, or pass the hostname explicitly.  

So if you tagged nodes with "service.NAME" then had a ${option.serviceName} option defined, you could do it this way:

* Generic service job (A). options: ${option.serviceName}, node filters: tags="service.${option.serviceName}"

* Specific service job. calls a Job Reference to (A), with arguments "-serviceName serviceA" 

If you wanted the hostname to be an input option to the base Job, you would have to pass that option along to the sub-job:

* Generic service job (A). node filters: hostname="${option.hostname}"

* Base job:  options: ${option.serviceName}, ${option.hostname}.  

  * Job reference arguments to (A): "-serviceName ${option.serviceName} -hostname ${option.hostname}"

--
Greg Schueler

--
You received this message because you are subscribed to the Google Groups "rundeck-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rundeck-discu...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Petzel]

Just realized I did a direct reply rather than group post.... posting back the meat of the discussion, for the sake of the group:

From Greg:

Job reference steps don't execute in a "node" context, as they run only once per-workflow, rather than per-node. So ${node.name} wouldn't evaluate to anything when passed to a Job reference.

There have been requests for this kind of functionality: allowing the Job Reference step to override the nodes defined in the Job, however we don't have that feature yet.  Every Job Reference will execute with the nodes defined in the Job it points to.  

The workaround is to use the node filtering + option definitions creatively, and pass options into the job reference :)

 

So essentially what I was trying to do can't quite be done as things sit to today. For the short term, I am going to look to implement some job templates using my configuration management solution, and essentially create multiple copies of the restart job in each section that I need it. Thus I can easily make updates to the template, and have all the copies stay in sync.

It would be a really nice feature if the job reference step, could have access to the node context.

Thanks