Apparently we are supposed to upgrade all our templates to include Packer Init, but there again it says here that “if you prefer not to use the required_plugins block you can continue to install plugins manually”
If you are working in an environment where you can’t connect to the Internet and have to install plugins manually, is there any point in upgrading the template with packer init?
Hi @steven,
If you’re offline completely indeed, packer init won’t be able to do anything since it requires an internet connection in order to fetch plugins from github.com.
Regarding required_plugins in a case like this, it’s mostly informative, as you will know which plugins are required to build the image, but it is limited practically indeed.
Out of curiosity since we’re on the topic of manually installing plugins, we’re working on changing how plugins work with Packer, especially regarding cases like required_plugins/manual installation, have you read our blog post regarding this?
Our documentation is not up-to-date yet with regards to those changes, but I’d be curious to know if you’re already using some of the commands we’re promoting, or if the upcoming changes won’t impact your workflows.
If you have a chance to test Packer 1.11.0-alpha that’d be great so we can catch/document potential issues with those upcoming changes.
Thanks in advance, hope that helps!
Thanks for that information - no, I hadn’t seen that blog before - it would have helped. I didn’t realize “packer plugins install --path” would have installed the plugins (vsphere-iso, vmware) exactly where they needed to be. As it was I installed in a dev server and worked it out, then copied manually in to prod.
Nevertheless, it was still easier than installing powershell modules offline.
I may or may not add required_plugins in to the code. As you say, it won’t help from an ease-of-installation point of view, but it would make the code more readable/usable, I suppose.
I think the most difficult aspect of all this is that it’s almost assumed that everyone is connected to the Internet still, which isn’t the case.
Hi!
I’m also a bit confused about how to manually install “private” plugins from v1.11 going forward.
Previously, as the old docs stated, I simply copied the plugins to Packer’s plugin directory, but should we now do packer plugins install –path <path-to-downloaded-extracted-binary> instead?
Has it changed? I’m on 1.10.1 and I just copy them to:
~/.config/packer/plugins/github.com/hashicorp/vmware/
… and on Windows it is installed in:
%AppData%Roaming\packer.d\plugins\github.com\hashicorp\vsphere
“packer plugins install /?” results in a message:
“Invalid plugin source string; The ‘source’ attribute must be in the format ‘hosname/namespace/name’”, which implied that plugins install only work on online installations.
Yeah that’s what I still do currently, but I cannot find the according docs anymore.
However, with v1.11 I understand this to be done differently using packer plugins install –path <path-to-downloaded-extracted-binary>, but I might misunderstand.
@lbajolet-hashicorp @nywilken could you please clarify?
Sorry for the confusion.
Hi @ChristoWolf / @steven,
I’ll try to clarify as much as possible sure, let me know if there’s something we need to re-explain.
Please note that the docs are not yet completely updated in preparation for 1.11.0, so right now the docs we have on https://developer.hashicorp.com/ are still for v1.10.x and will change when 1.11.0 is out the door.
There are preview docs available for 1.11.0, but even at that, we are working on updating them before the release happens.
Copying plugin binaries to $PACKER_CONFIG_DIR/plugins will not work as-is anymore starting with 1.11.0, and instead we do advise you use packer plugins install --path to install your plugins, if you cannot use packer init for this.
packer init is the simplest method, with the main drawback being that the source has to be github.com in order for it to be able to install the plugins. We plan to address this limitation in an upcoming release, please bear with us for now. Being coupled with required_plugins in the template, this also has the merits of documenting the requirements, and pointing to a URI where one can find the binaries.
Now to be fair you could still install plugins the hard way, by moving them into the plugins directory, under a filesystem hierarchy that matches the source defined for the plugin, with a naming convention that Packer requires (already the case for required_plugins), and an accompanying sumfile. Please note though that while technically possible, we don’t support this explicitly and this will be undocumented as an installation method.
If you want to understand this and play with it, feel free to take a look at the implementation for packer plugins install --path, as this is essentially what you will need to manually replicate.
If only to make sure you are comfortable before that hits GA, I would suggest you try out the beta we released almost two weeks ago.
To answer @steven’s comment:
“packer plugins install /?” results in a message:
“Invalid plugin source string; The ‘source’ attribute must be in the format ‘hosname/namespace/name’”, which implied that plugins install only work on online installations.
This happens because the help function for packer commands is --help, anything that isn’t following this convention is considered an argument to the command, and /? is indeed an invalid source for fetching a plugin from.
Hope this helps clarify your questions, feel free to update this thread again if you need more help.
Thanks for the extensive response @lbajolet-hashicorp, my questions are more than answered 
@lbajolet-hashicorp looks like I still don’t get the full picture 
<hostname>/<namespace>/<plugin-name> still required?Thanks for your help!
Hi @ChristoWolf,
I’ll try to answer your questions one-by-one:
You need a source for a plugins, this was optional pre 1.11, this is now mandatory. Sources are not however necessary <hostname>/<namespace>/<plugin-name>, you can have URLs with up to 16 components in their path. We require it for:
a. remote installation: you need a source to be able to remotely install a plugin
b. documentation: you know where to look for if you want to get a plugin binary
c. deambiguation: the source makes it clear which plugin you want (ex: github.com/hashicorp/amazon vs. gitlab.com/hashicorp/amazon)
d. practical reasons: the plugin binary doesn’t report a source, so the burden of providing it befalls the user
Non-Github repos are able to be manually installed, but not remotely. Suppose you have a plugin sourced from Gitlab to install, it’d be something like this: packer plugins install --path ./my-plugin-binary "gitlab.myorg/organisation/group/subgroup/packer-plugin-project". This will install your binary under for example $PACKER_PLUGIN_PATH/gitlab.myorg/organisation/group/subgroup/project/packer-plugin-project_v0.1.1_x5.0_linux_amd64. You will also be able to add a required_plugins block to a template to require this plugin.
Not sure what your question is here but I’ll try to address it. For mono-repos with several packer plugins, you will need at least some different source name between both plugins. This is not a use-case we support necessarily, but you can conceivably make it work by addressing different directories in that repo. Say you have a coolcloud and a happycloud plugin in your repo, under two directories, these could be marked as two different sources.
I would suggest if you didn’t already to take a look at our Upgrade to v1.11 docs as well if something isn’t clear in my response. If you see something unclear in the docs also let me know, we can probably fix it.
Thanks!
@lbajolet-hashicorp: Thank you again for all your extensive help, now I think I get it, at least I got it to work after some attempts
I guess what could be useful for the documentation is to include a guide on how to properly format/translate plugin source URLs s.t. they satisfy Packer.
E.g.
packer-plugin- even when the repo/module name includes it.<hostname>/<collection>/<project>/_git/<repo name>?path=%2F<plugin name>%2Fpacker-plugin-<plugin name>.<hostname>/<collection>/<project>/_git/<repo name>/<plugin name>/<plugin name>, which worked fine!I know, probably not the best how I do it, but this is mainly motivated by restrictions at work.
Thanks again!