Rollback button

[stephanos]

👋 Hello there,

here at PagerDuty my team just started using Nomad and we have one burning wish for the UI: have a rollback button.

Sometimes when things don't go as planned, it's necessary to rollback to the version before. Now, in our old cluster manager there was a version history with an "apply" button next to each one. Rolling back took a few seconds.

Now with Nomad, unless I'm missing something, the first job you have is to figure out what was deployed before. Once you have that, you need to redeploy with that tag. It takes a while, especially when you are under stress because the system isn't healthy.

I'd love to see this in the UI.

Is this possible? Is this something you'd consider?

[josegonzalez]

Looks like it should be possible to:

• Have a UI with all job versions available (looks like its 5 by default?).
• Have a revert button to any of those versions.
• Have a revert button to a specific version.

Here is some pseudo-code to do so via shell:

JOB_NAME=api
VERSION="$(nomad job inspect "$JOB_NAME" | jq '.[].Version')"
OLD_VERSION=(( VERSION - 1 ))
nomad job revert "$JOB_NAME" "$OLD_VERSION"

@stephanos is this something you would consider submitting as a pull request?

[stephanos]

@josegonzalez thank you for your quick reply. Yes, that's what I was imagining!

I haven't looked at the code yet, so I don't know how much work that would be. In theory, I'd love to. I'll have to talk to me team whether we have the expertise/time to contribute.

[jippi]

@stephanos i (hope) the code is quite simple to work with - there is light docs on working with it locally too - otherwise I'm around here or HangOps slack as Jippi if you need help/guidance :)

[stephanos]

First of all, I was looking at the UI a bit to figure out how I'd do it, and was wondering, does it make sense to put it here?

This is an old version and it would probably be very easy to put a "Rollback" button there. That would make this UI change fairly easy, I think.

Second of all - and I'm a Nomad newbie so bear with me - I'm not sure nomad job revert is very transparent. I just tried it on the console and I expected it to create a new version. But instead it changed the state of the existing version by starting a new task with the previous deploy config. Personally, I find this very confusing. Because it's very hard to track down which Docker image is actually being run now. Long story short, is there a nomad command to trigger a new version with the previous configuration to be executed?

[jippi]

@stephanos i think its a good place indeed - i need to rework the versioning thing quite a lot, but for now its a good spot yes

unfortunately nomad deploy versions / revert work as you already discovered - so i would prefer our reverting to use those native primitives - even if i agree with your observations that its kinda odd :)

[josegonzalez]

Might be good to have a history page and then be able to revert from there? The page could show all historical versions that are available, and then a revert button on the side of each jobs - it could even show a diff between each job version :)

[stephanos]

@jippi I just discovered nomad job history and nomad job dispatch. Would it be theoretically possible to take the output from job history and pipe it into job dispatch? (I haven't looked at the source code yet) By that I mean to take the job config from the previous version and use it to "deploy" it again. If it is possible, would that be a viable approach for you? I don't know if my team would want to invest time into a solution we'd not be happy with (the nomad job revert).

@josegonzalez I agree! But I'd be out of scope for me.

[jippi]

@stephanos yeah, but it would have to be made clear its revert, but not real revert - we already got some opinionated features in hashi-ui, so adding them is fine - as long as they are labelled clearly as such

[stephanos]

Sounds good. My team is okay with tackling this some time in October.

[donparapidos]

Hi there! Just wondering, how is it with this functionality, will it be implemented ?

[stephanos]

Well, things changed 😅 and we soon introduced a Continuous Deployment so we just go in there and hit "Deploy" (of a previous build) again. This solves our use case. So unless someone else picks this up, we can go ahead and close it.