Skip to content
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

FEATURE REQUEST: Common 'enabled' parameter for provisioners and post-processors #7864

Closed
pommetjehorlepiep opened this issue Jul 10, 2019 · 6 comments
Labels
core Core components of Packer enhancement stage/duplicate

Comments

@pommetjehorlepiep
Copy link
Contributor

After using packer for a while, I came to the conclusion that it's not easy to skip provision steps.

I had a chef-solo provisioner which only had to be executed in certain cases. I ended up basically running the provisioner without a recipe in cases where I wanted to skip that step. A bit clunky.

It would've been so much easier if there was a common 'enabled' parameter available which by default = 'true'. Setting 'enabled' to 'false' would result in this step to being skipped.

Same would be handy for post-provisioners as well.

@SwampDragons
Copy link
Contributor

Have you checked out our https://www.packer.io/docs/templates/provisioners.html#build-specific-overrides ?

If those don't work for you, I'd like to hear a bit more about your template and your use case.

tl;dr from the docs link above:

You can make the provisioners skip by adding all the builds from a given template to an "except" statement.. Example:

The below provisioner will print "this ran" if the except line is removed, and won't print it if the except line is present.

{
	"builders": [
		{
			"type": "null",
			"communicator": "none"
		}
	],
	"provisioners": [
		{
			"except": ["null"],
			"type": "shell-local",
			"inline": ["echo this ran"]
		}
	]
}

@SwampDragons SwampDragons added enhancement question core Core components of Packer labels Jul 11, 2019
@pommetjehorlepiep
Copy link
Contributor Author

Have you checked out our https://www.packer.io/docs/templates/provisioners.html#build-specific-overrides ?

If those don't work for you, I'd like to hear a bit more about your template and your use case.

tl;dr from the docs link above:

You can make the provisioners skip by adding all the builds from a given template to an "except" statement.. Example:

The below provisioner will print "this ran" if the except line is removed, and won't print it if the except line is present.

{
	"builders": [
		{
			"type": "null",
			"communicator": "none"
		}
	],
	"provisioners": [
		{
			"except": ["null"],
			"type": "shell-local",
			"inline": ["echo this ran"]
		}
	]
}

Yes, that works, but it's is not an obvious or nice solution.

Example case:

I had a case where I was using Chocolatey resource using chef-solo provisioner to install an older version of Elasticsearch. This worked initially fine, until an underlying dependency in Chocolatey broke and the install of Elasticsearch failed.
For that particular version a powershell provisioner was used to do the install.
So I have 2 provisioners, which both can install Elasticsearch. Ideally I use the Chef provisioner, but in some cases I need to use the powershell provisioner.

If I can just disable 1 of the provisioners based on a variable than my problem is solved.

@SwampDragons
Copy link
Contributor

This still seems like exactly the situation that the only and except options were created for; if you're building similar machines with different dependencies, each machine should probably be generated by a different builder so that it's obvious that you're getting different machines out the end of the provisioning pipeline. Because the builders have different names, you can conditionally run provisioners based on which builder is running.

The way the Packer config is currently processed, we can't really do skips based on arbitrary variables. It would change the way we have to interpolate the templates. What you're asking for isn't really recommended practice but it's been asked for enough that we have a documented workaround here: https://www.packer.io/docs/templates/user-variables.html#making-a-provisioner-step-conditional-on-the-value-of-a-variable, or if you're feeling sassy you can probably create a wrapping script that preprocesses the Packer template with jq to remove the unwanted provisioner.

I do understand that it would be a nice from a user experience perspective to have an explicit skip-based-on-a-variable option, and maybe it's something we can revisit once we have more developers on Packer but it's not something I have the bandwidth to pursue before then. I'd say "PRs are welcome" but honestly I need to spend some more time thinking through the implications of endorsing this as a first-class template option. I strongly prefer the idea of builders only being able to trace one pathway through provisioning; I think it's a better and more explicit practice, and that any repetition caused by having to create an extra builder is worth the explicitness that's gained.

Thanks :)

@pommetjehorlepiep
Copy link
Contributor Author

pommetjehorlepiep commented Jul 14, 2019

I hear what you're saying.

The way I currently get around the problem is in the line of https://www.packer.io/docs/templates/user-variables.html#making-a-provisioner-step-conditional-on-the-value-of-a-variable (running chef-solo provisioner with an empty run-list).
That still runs the provisioner step though, and does nothing,
I'll try except/only and see if this is better suited.

UPDATE:
Can't use except/only. Doesn't accept user variables... so for me conditional is the way to go.

@SwampDragons
Copy link
Contributor

doing some cleanup -- this one was kind of a dupe of #4895

@ghost
Copy link

ghost commented Mar 28, 2020

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.

@ghost ghost locked and limited conversation to collaborators Mar 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core Core components of Packer enhancement stage/duplicate
Projects
None yet
Development

No branches or pull requests

2 participants