Allow Node Filter to be provided on execution time #1754

Closed
adrianshum opened this Issue Mar 17, 2016 · 4 comments

Projects

None yet

5 participants

@adrianshum

It is a bit similar to #114, but going one step further.

Currently with #114, what we can do is, when defining jobs, we provide a node filter. And when running the job, we will be given a list of node to enable/disable individual node.

I am aware that I can add a text option (e.g. NodeFilter), and put ${option.NodeFilter} in node filter. However it does not give a proper preview on what nodes is going to run the job. Is it possible to allow the Node Filter to be inputted when Prepare and Run, so we can click on the Search button to give us list of node to run the job.

Further more, with combination of "The user has to explicitly select target nodes", we may even allow explicitly enabling/disabling the searched result.

This give us more flexibilities in submitting a general job to servers that we want on runtime

@puremourning

+1 to allowing a node filter (like in the Commands page, Nodes page) to the prepare and run of a job. This would hugely improve our workflow.

To add a use-case, we have Envrionments which comprise many different nodes of many different types. Often we will run an uber-job over and entire environment, let's call it "TEST_ENV_1". We use node properties (e.g. MyStuff:Evironment: ${option.Environment}). This uber-job runs many other more specific jobs against subdivisions of the environment, e.g. a jobref with node filter MyStuff:Environment: ${option.Environment} tags: server_type_a Role:STANDBY then the same jobref with MyStuff:Environment: ${option.Environment} tags: server_type_b Role:PRIMARY.

I would often just run the sub-job, using a similar filter, as the uber-job takes a long time and has highly disruptive impact. It is impractical and error-prone to manually extract the nodes using the Nodes panel, then manually search through a long list of user@host to tick the ones that would have matched.

The best workaround seems to be to create an ad-hoc job which just calls the sub-job with the filter set up, but that is quite cumbersome.

Many thanks!!

@reillye6

+1

@yosefy
yosefy commented Aug 2, 2016

+1

@gschueler gschueler added this to the 2.7.0 milestone Aug 2, 2016
@gschueler
Contributor

implemented in #2110

@gschueler gschueler closed this Nov 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment