RFE: Schedule jobs based on other scheduled job

[msilmser]

ISSUE TYPE

• Feature Idea

SUMMARY

Add the ability to schedule a job to run based on the run of another job. See the following use case:

I have scheduled a job to run every 2nd Tuesday of the month within tower. 
Then I'm looking to run  a job against my test servers the following Saturday so T+4 days
Then a job the week after - T+11 days
And last a job two weeks after the previous - T+25days

The current ability to use 2nd or 3rd days of the week do not allow the flexibility this model does because in some instances, the 2nd Saturday may come after the 2nd Tuesday.

[wenottingham]

This seems better off by creating a workflow that creates and schedules one-offs for jobs 2-4, and schedules that.

[SzosszeNET]

This seems better off by creating a workflow that creates and schedules one-offs for jobs 2-4, and schedules that.

Can you elaborate this through an example please? Looked at creating workflows, but struggling to see how the T+xdays could be implemented there.

[wenottingham]

You'd need to compute the rrule for 'run once two weeks from now', and post a schedule that does that.

[sumkincpp]

Though, this might be less related to the initial issue, but I highly believe that there is also a need for schedules dependent on other schedules.

It will hugely help for Operators since you are not giving a big tool(Workflow Editor with Workflow dependent jobs) with which they may shoot their foot. They don't want to build workflows, they want to execute them!

Example usecase - providing to operator set of workflows

• Provision Networking Device
• Provision Networking Transport (i.e. VRF, MPLS LSP Path, BGP VXLAN EVPN)
• Configure Access Configuration (exact application or service, which faces server from network device)

Second and third steps are usually complex and require big sets of params.

But! Current Workflows in Workflows are also helpful when you know about static layout of the network, It's really simple and nice to make separate Workflows for access, distribution and core and bundle them alltogether in one "Provision Transport everythere" workflow, which also simplifies life of operator/engineer.

Depending on exact request to Operators Team and maintenance time, for operator it way better to schedule dependent jobs(of N steps). Currently putting all at once might not work since one of the fundamental(or required) tasks may fail - Consider that networking transport was not provisioned successfully, so no need for trying to configure access configuration.

Initial closed issue is #2990

@wenottingham, @ryanpetrello what do you think?