Packer: FEATURE: run a custom script with --on-error=cleanup

[atifrasheed79]

Hi Devs,

Can we have an option to run a custom script with --on-error=cleanup before packer starts the default cleanup?

We are subscribing to RHEL Satellite in start of the build process and then unsubscribe at the end when build finishes. Now if build fails in middle, the unsubscribe commands doesn't run which leaves zombie subscriptions in the Satellite which is managed by another team.

Option of running a custom script will help us to implement try/catch and do our cleanup before packer starts it's default cleanup.

Thanks.

[SwampDragons]

Hm, interesting. Why do you need to run the unsubscribe command before Packer's default cleanup? Why not just wrap packer in a shell script that will run the unsubscribe after Packer's run, regardless of whether it errors or not?

[pkleanthous-zz]

@SwampDragons Do you have any updates on this?

Shell script it's not a good option as it will need username, ip address & ssh key for that.
In a happy path scenario the unsubscribe can be the last provisioner. When a we face a falure in another provisioner, packer jumps directly to cleanup stage.

[SwampDragons]

That makes sense, thanks for the explanation.

[SwampDragons]

As far as updates are concerned: currently, this isn't on the roadmap. I do think it's a good idea, and I would absolutely review a PR for it, but I am not sure when I'll be able to prioritize implementing it myself.

[atifrasheed79]

Hi @SwampDragons, apologies as I believed I have already answered your question :) Just came back to the thread today and realized that I have not.

However, shell script option is not applicable in our case as I mentioned earlier that we do Satellite subscription in the build process and by build process I mean it happens in the temporary instance launched by the Packer. Now if the build process fails, the temporary instance is destroyed and what we want is that we should have an opportunity to do some clean up before Packer destroys the temporary instance.

Hope this clarifies! please do let me know if I am still not making sense to you :).

[SwampDragons]

@atifrasheed79 Thanks, that all makes sense. I like this idea but it may be some time before I get a chance to implement it. I'm doing roadmap work right now; I'll see if I can figure out a good place to fit this in.

[SwampDragons]

From #7383:

We would like to always (think finally from the try/catch/finally pattern) try to run a "final" provisioner step on our instances prior to running the shutdown / cleanup steps.

As part of our image build process we register/subscribe our Instances/VMs to Satellite so that we can install packages. When a build fails for some reason this can then result in 'subscribed' instances which no longer exist. We would like to be able to run a final provisioner step which we can then use to unregister prior to shutting down and destroying the Instance/VM. The image build should still count as 'failed' if a previous provisioner failed, and failure of this provisioner would be no different to any other provisioner failing, but would give us a way to cleanly fail instead of eating up entitlements that have to be manually cleaned up.

[SwampDragons]

I've been working on implementing this and I have a question -- does the satellite subscribe/unsubscribe happen from within the vm, or on the build host? (Are you using the shell provisioner for this, or shell-local)?

[tremble]

@SwampDragons this would be scripts running within the VM

[atifrasheed79]

Yes @SwampDragons, like @tremble mentioned, subscribe (is part of the script which) happens within the virtual machine and we want to do unsubscribe as well within the virtual machine before the temporary instance is destroyed.

[SwampDragons]

Rad. I'll have something for y'all to test out this week.

[SwampDragons]

Here it is: https://circleci.com/gh/hashicorp/packer/14127#artifacts/containers/0

A usage example can be found in the PR: https://github.com/hashicorp/packer/pull/8155

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.