New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Old or new job versions run after modification #1447

Open
rocso opened this Issue Sep 15, 2015 · 7 comments

Comments

Projects
None yet
8 participants
@rocso

rocso commented Sep 15, 2015

Hi,

I'm currently running RunDeck version 2.5.1-1. This is a production system and I have not yet upgraded to the latest version of RunDeck. I have checked the lists of bug fixes in the later releases but did not see any matching the following issue

Scenario: I have a job defined that is running reliably as a scheduled job. I then edit the job in order to change a step. Subsequent [scheduled] runs will now sometimes run the old version and sometimes the new version.

The way I'm using RunDeck is generally but not always as follows (through the GUI):
I define single-purpose jobs that I don't schedule but can run manually to test or recover,
I then define a job that calls these single-purpose jobs as workflow steps, that I then schedule as needed.

The problem occurred after I defined a new single-purpose job and added it as a new step in the scheduled job. For example, I modified the job scheduled for 00:05 each day on Friday and it ran the new version fine on Sat, Sun, Mon but on Tuesday for no explicable reason it ran the old version. Nothing in RunDeck was changed over this period.

If I list the job definition either in the GUI or via rd-jobs I see only the latest version.

This is the second time this has happened with this same job. The first time IIRC I simply added an option and may have rearranged the ordering of a couple of steps via the GUI. The second time I added a new step and removed an old step via the GUI.

I'm currently trying to work around the issue by duplicating the scheduled job and then deleting the original, assuming that this might disambiguate the job versions.

@ecoron

This comment has been minimized.

Show comment
Hide comment
@ecoron

ecoron Sep 15, 2015

Hi,
we noticed the same issue, sometimes is an older version of scheduled job executed.
We are on Version 2.5.3

ecoron commented Sep 15, 2015

Hi,
we noticed the same issue, sometimes is an older version of scheduled job executed.
We are on Version 2.5.3

@gschueler gschueler added the bug label Sep 15, 2015

@ecoron

This comment has been minimized.

Show comment
Hide comment
@ecoron

ecoron Sep 18, 2015

as a workaround we do the trick to disable the scheduler (and save the job)
after doing the changes in job we enable the scheduler again. the result is no more random execution of old or new version of the job definition.

ecoron commented Sep 18, 2015

as a workaround we do the trick to disable the scheduler (and save the job)
after doing the changes in job we enable the scheduler again. the result is no more random execution of old or new version of the job definition.

@wricardo

This comment has been minimized.

Show comment
Hide comment
@wricardo

wricardo Oct 5, 2015

I'm having the same issue here. I'm running version 2.5.0-1

wricardo commented Oct 5, 2015

I'm having the same issue here. I'm running version 2.5.0-1

@pvanacker

This comment has been minimized.

Show comment
Hide comment
@pvanacker

pvanacker Apr 11, 2016

This issue is still present on version 2.6.2.
Is there a correction planned ?
Thank you

pvanacker commented Apr 11, 2016

This issue is still present on version 2.6.2.
Is there a correction planned ?
Thank you

@DJHills

This comment has been minimized.

Show comment
Hide comment
@DJHills

DJHills Aug 9, 2016

I have also just observed the issue in version 2.6.2.

DJHills commented Aug 9, 2016

I have also just observed the issue in version 2.6.2.

@danifr

This comment has been minimized.

Show comment
Hide comment
@danifr

danifr Nov 15, 2016

Contributor

Hi @gschueler,

I had this issue today (v2.6.2). I don't know if it is still present on newer versions of Rundeck.
In my case, the scheduled job was run using an old option instead of the one that was supposed to use.

Is there a way I can check against the database what are the last options used for a certain job and who modified it and when? I'd like to check if it was actually a bug or a human error.

Thanks a lot!

Contributor

danifr commented Nov 15, 2016

Hi @gschueler,

I had this issue today (v2.6.2). I don't know if it is still present on newer versions of Rundeck.
In my case, the scheduled job was run using an old option instead of the one that was supposed to use.

Is there a way I can check against the database what are the last options used for a certain job and who modified it and when? I'd like to check if it was actually a bug or a human error.

Thanks a lot!

@ahonor

This comment has been minimized.

Show comment
Hide comment
@ahonor

ahonor Nov 17, 2017

Contributor

Curios if the SCM plugins will satisfy managing the versions.

Contributor

ahonor commented Nov 17, 2017

Curios if the SCM plugins will satisfy managing the versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment