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

manifestdir is deprecated in Puppet 3.6.0 #3740

Closed
ferventcoder opened this issue May 9, 2014 · 74 comments
Closed

manifestdir is deprecated in Puppet 3.6.0 #3740

ferventcoder opened this issue May 9, 2014 · 74 comments

Comments

@ferventcoder
Copy link

@ferventcoder ferventcoder commented May 9, 2014

manifest now has the ability to take a directory or fully qualified path to a manifest file. If it is a directory it will parse all files in there and run the result.

Heads up what you are going to start seeing issues on:

==> default: Running provisioner: puppet...
Running Puppet with /tmp/vagrant-puppet-4/manifests/site.pp...
Warning: Setting manifestdir is deprecated. See http://links.puppetlabs.com/env-settings-deprecations
(at c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/settings.rb:260:in block (2 levels) in parse_global_options'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/puppet_option_parser.rb:81:incall'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/puppet_option_parser.rb:81:in block in pass_only_last_value_on_to'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/trollop.rb:432:incall'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/trollop.rb:432:in block in parse'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/trollop.rb:393:ineach'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/trollop.rb:393:in parse'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line/puppet_option_parser.rb:74:inparse'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/settings.rb:270:in parse_global_options'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/settings.rb:239:ininitialize_global_settings'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet.rb:150:in do_initialize_settings_for_run_mode'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet.rb:136:ininitialize_settings'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb:86:in block in execute'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:479:inexit_on_fail'; c:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb:85:in execute'; c:/Program Files/Puppet Labs/Puppet/puppet/bin/puppet:4:in

')

I'm thinking we can change the provisioner from this:

 config.vm.provision :puppet, :options => ["--debug --trace --verbose"] do |puppet|
    puppet.manifests_path = "puppet/manifests"
    puppet.manifest_file  = "site.pp"
    puppet.module_path = "puppet/modules"
  end

to this:

 config.vm.provision :puppet, :options => ["--debug --trace --verbose"] do |puppet|
    puppet.manifest_file  = "puppet/manifests/site.pp"
    puppet.module_path = "puppet/modules"
  end

or try something else? Thoughts?

From my comments below, leave the Ux the same and merge the options together and provide them to puppet as one setting.

@ferventcoder
Copy link
Author

@ferventcoder ferventcoder commented May 9, 2014

@zaphod42 this sum it up?

@ferventcoder ferventcoder changed the title [Enhancement] Puppet Shell provisioner - manifestsdir is deprecated in Puppet 3.6.0 [Enhancement] Puppet Shell provisioner - manifestdir is deprecated in Puppet 3.6.0 May 9, 2014
@ferventcoder ferventcoder changed the title [Enhancement] Puppet Shell provisioner - manifestdir is deprecated in Puppet 3.6.0 [puppet-provisioner] manifestdir is deprecated in Puppet 3.6.0 - may require changes to provisioner interface May 9, 2014
@ferventcoder
Copy link
Author

@ferventcoder ferventcoder commented May 9, 2014

Alternatively, it could stay the same and the options merge to provide manifest as one setting.

@mitchellh
Copy link
Member

@mitchellh mitchellh commented May 9, 2014

Yeah I think the options staying the same works. I think internally we can just continue to share that folder and then just change the way that we are calling Puppet.

@zaphod42
Copy link

@zaphod42 zaphod42 commented May 9, 2014

👍 the --manifestdir option (and setting) is going away as part of the directory environment work.

@narkisr
Copy link

@narkisr narkisr commented May 26, 2014

A fix for this will be great

@pcriv
Copy link

@pcriv pcriv commented May 28, 2014

+1

1 similar comment
@gustavoca
Copy link

@gustavoca gustavoca commented May 28, 2014

+1

@feresr
Copy link

@feresr feresr commented Jun 4, 2014

Same problem here, and I'm only using

config.vm.provision "puppet"

@sitle
Copy link

@sitle sitle commented Jun 14, 2014

I'm stuck with this problem. Can you submit a patch for this please ?

++1

@ttsuchi
Copy link

@ttsuchi ttsuchi commented Jun 17, 2014

+1

2 similar comments
@salimane
Copy link
Contributor

@salimane salimane commented Jun 21, 2014

+1

@KerryJones
Copy link

@KerryJones KerryJones commented Jun 23, 2014

+1

@Stoosh
Copy link

@Stoosh Stoosh commented Jul 14, 2014

+1

1 similar comment
@kensykora
Copy link

@kensykora kensykora commented Jul 25, 2014

👍

@benh57
Copy link
Contributor

@benh57 benh57 commented Aug 5, 2014

I can take a look at patching this.

We can add a new setting to simply pass in environmentpath directly from vagrant, which will override the manifest and modulepath settings. We could also allow folks to pass in an environment.

If environmentpath is not passed in was thinking we could create a temp environment dir with an environment.conf in it which is generated using the passed-in from Vagrantfile modulepath and manifestfile settings.

@rasschaert
Copy link
Contributor

@rasschaert rasschaert commented Aug 6, 2014

Can't use the puppet provisioner anymore so I've been using this workaround until this issue is addressed:

    config.vm.provision :shell, inline: 'sudo puppet apply --environment dev \
      --pluginsync --hiera_config /etc/puppet/hiera.yaml \
      /etc/puppet/environments/dev/manifests \
      --environmentpath /etc/puppet/environments'

...along with some synced_folders to put the manifests and hiera files in the right folders.

@ferventcoder
Copy link
Author

@ferventcoder ferventcoder commented Aug 6, 2014

What? Why can't you use the puppet provisioner anymore? A deprecation
warning is what this issue is about.

On Wednesday, August 6, 2014, Kenny Rasschaert notifications@github.com
wrote:

Can't use the puppet provisioner anymore so I've been using this
workaround until this issue is addressed:

config.vm.provision :shell, inline: 'sudo puppet apply --environment dev \      --pluginsync --hiera_config /etc/puppet/hiera.yaml \      /etc/puppet/environments/dev/manifests \      --environmentpath /etc/puppet/environments'

...along with some synced_folders to put the manifests and hiera files in
the right folders.


Reply to this email directly or view it on GitHub
#3740 (comment).

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

@rasschaert
Copy link
Contributor

@rasschaert rasschaert commented Aug 6, 2014

Oh, I think I wanted to post that comment under issue 3402. I had a couple of tabs open with open puppet privisoner issues. My bad.

@lmayorga1980
Copy link

@lmayorga1980 lmayorga1980 commented Aug 11, 2014

Is this already merged? to 1.6.3?

@ferventcoder
Copy link
Author

@ferventcoder ferventcoder commented Aug 11, 2014

@rasschaert no worries. :)

@benh57
Copy link
Contributor

@benh57 benh57 commented Aug 11, 2014

@lmayorga1980 as far as i know no one's implemented this yet. I planned to take a look at it soon if no one else does.

@vpassapera
Copy link

@vpassapera vpassapera commented Sep 5, 2014

+1

1 similar comment
@fe-lix-
Copy link

@fe-lix- fe-lix- commented Sep 8, 2014

+1

@rbu
Copy link

@rbu rbu commented Sep 10, 2014

Deprecation warnings should be fixed so we can upgrade before it breaks.

@martijn
Copy link

@martijn martijn commented Sep 1, 2015

So Vagrant 1.7.4 still calls puppet with --manifestdir, yet newer boxes like centos-7.0-64-puppet 1.0.2 include a version of Puppet that no longer supports this parameter. Seems like that needs fixing.

@thenexxuz
Copy link

@thenexxuz thenexxuz commented Sep 5, 2015

This helped me at least get up and running without needing to do much work on updating a lot of things.

I added this to my Vagrantfile after the config.vm.box line:
config.vm.box_version = "1.0.1"

@codesplicer
Copy link

@codesplicer codesplicer commented Sep 8, 2015

+1
Still facing this issue with Error: Could not parse application options: invalid option: --manifestdir using the puppetlabs/ubuntu-12.04-64-puppet box at v1.0.2, which ships with puppet v4.2.1. As @thenexxuz suggested, using v1.0.1 of this box is compatible as it ships with puppet v3.7.4

@jbeard6
Copy link

@jbeard6 jbeard6 commented Sep 8, 2015

For what it's worth, I have worked around this issue by using a script provisioner to invoke puppet apply directly. This not only has the benefit of working, but also more closely replicates how puppet will actually be used in a production environment to apply my config.

Still, I'm looking forward to having this issue resolved. This has been a long time coming.

@ball-hayden
Copy link

@ball-hayden ball-hayden commented Sep 8, 2015

I have been working around this by placing the contents of https://github.com/benh57/vagrant/tree/environments_wip/plugins/provisioners/puppet into lib/puppet in my project directory, adjusting the plugin name to puppet4, then adding require_relative 'lib/puppet/plugin.rb' at the top of my Vagrantfile. This allows me to use a 'puppet4' provisioner, which works correctly.

@benh57
Copy link
Contributor

@benh57 benh57 commented Sep 9, 2015

With puppet 4 you need to switch your Vagrantfile to use puppet environments, instead of the manifest file setting. This is documented in the vagrant docs. I'm not sure how that premade box is set up, but i can try it out.

@benh57
Copy link
Contributor

@benh57 benh57 commented Sep 9, 2015

  • One would assume if you pass a path to manifest file, that you want to use that manifest file (and the old option).

I suppose i could, if an environment file is not specified, make a 'fake' environment file, pointing at the specified manifest file. However, that would only work going back a couple versions of puppet, i think it would work on 3 or later? We have no autodetection of puppet version, but that could potentially be added.

@benh57
Copy link
Contributor

@benh57 benh57 commented Sep 9, 2015

@ball-hayden I think all of that branch ('environments_wip' ) made it into Vagrant 1.7.4, didn't it? Maybe it was broken later by another change?

@benh57
Copy link
Contributor

@benh57 benh57 commented Sep 9, 2015

@jbeard6 It was fixed. If you're using puppet 4, pass your environment. This will put it into environments mode.

puppet.environment = "production"
puppet.environment_path = "path/to/environments/on/host"

(and optionally, the path to a manifest - which will override the environment's manifest if you set it!)

puppet.manifests_path = "puppet/manifests"
puppet.manifest_file = "site.pp"

If you JUST to the last 2 settings, we assume that you are on puppet <4, and pass --manifestdir.

In other words -- this bug is not a bug anymore.

  • I am open to a solution like adding autodetection of the puppet version so that vagrant can be more smart, if folks desire this.
@codesplicer
Copy link

@codesplicer codesplicer commented Sep 9, 2015

@benh57 This solution assumes that you are in fact using puppet environments with a puppet master, which isn't the case for those of us operating puppet masterless.

@codesplicer
Copy link

@codesplicer codesplicer commented Sep 9, 2015

For the record I managed to workaround this issue by using symlinks. Given the following folder tree:

project_foo
    \ puppet
        | puppet.conf
        \ modules
        \ manifests

I created a new folder environmentswhich contained a symlink to the puppet folder in the project_foo folder

project_foo
    \ puppet
    | puppet.conf
        \ modules
        \ manifests
        \ environments
            \ production    <-- Symlink to ../../

Then in my Vagrantfile, as suggested by @benh57 I added the following:

config.vm.provision "puppet" do |puppet|
    puppet.environment = "production"
    puppet.environment_path = "puppet/environments"
    puppet.manifests_path = "puppet/manifests"
    puppet.manifest_file = "vagrant.pp"
    ...

Its a somewhat dirty hack but it works for now.

@adamcstephens
Copy link

@adamcstephens adamcstephens commented Sep 9, 2015

As can be seen by the removal of manifestdir (following the original deprecation notice), environments are intended for both puppet apply and agent. vagrant has support for this now, so I agree with @benh57 that this is no longer a bug.

See BREAK: Directory Environments Replace Config File Environments here: http://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html

@l0b0
Copy link

@l0b0 l0b0 commented Sep 9, 2015

@adamcstephens From reading Directory Environments Replace Config File Environments and the linked documentation I don't see how it's possible to use environments with masterless Puppet. Some relevant quotes:

Creating Environments:

[The environment] must be located on the Puppet master server(s)

What if I don't have a master at all, even less a separate server? There doesn't seem to be any mention of masterless Puppet in this article.

About Environments:

A Puppet master server can serve each environment with completely different main manifests and modulepaths.
[...]
In Puppet manifests, you can get the name of the current environment by using the $environment variable, which is set by the Puppet master.

Again, what about masterless Puppet?

$environment configuration reference:

For clients (e.g., puppet agent) this determines the environment itself, which is used to find modules and much more. For servers (i.e., puppet master) this provides the default environment for nodes we know nothing about.

No mention of puppet apply. In fact all the documentation around environments seems to assume a master/agent setup, and doesn't mention (in any way I have been able to discover) how it applies to masterless Puppet.

Can you please reopen this bug, or else direct the 30+ people who are interested in this to some documentation on how to do the transition to masterless Puppet environments, if possible?

@benh57
Copy link
Contributor

@benh57 benh57 commented Sep 12, 2015

I use vagrant with my environments all day with no puppet master, to test
my configurations for (later) use with the puppet master server.

It's just a named folder, with an environment.conf file in it. I'm not sure
how that's a hack, since it's the intended puppet (4) way.

Maybe it would be 'cleaner' if vagrant would detect your puppet version and
'just work' and help you out by 'faking' an environment ? That seems almost
more of a hack. Though it would have the benefit that existing Vagrantfiles
would continue to work. Perhaps vagrant could warn..

On Wed, Sep 9, 2015 at 6:36 AM, Victor Engmark notifications@github.com
wrote:

@adamcstephens https://github.com/adamcstephens From reading Directory
Environments Replace Config File Environments
https://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html#break-directory-environments-replace-config-file-environments
and the linked documentation I don't see how it's possible to use
environments with masterless Puppet. Some relevant quotes:

Creating Environments
https://docs.puppetlabs.com/puppet/latest/reference/environments_creating.html
:

[The environment] must be located on the Puppet master server(s)

What if I don't have a master at all, even less a separate server? There
doesn't seem to be any mention of masterless Puppet in this article.

About Environments
https://docs.puppetlabs.com/puppet/latest/reference/environments.html:

A Puppet master server can serve each environment with completely
different main manifests and modulepaths.
[...]
In Puppet manifests, you can get the name of the current environment by
using the $environment variable, which is set by the Puppet master.

Again, what about masterless Puppet?

$environment configuration reference
https://docs.puppetlabs.com/references/4.2.latest/configuration.html#environment
:

For clients (e.g., puppet agent) this determines the environment itself,
which is used to find modules and much more. For servers (i.e., puppet
master) this provides the default environment for nodes we know nothing
about.

No mention of puppet apply. In fact all the documentation around
environments seems to assume a master/agent setup, and doesn't mention (in
any way I have been able to discover) how it applies to masterless Puppet.


Reply to this email directly or view it on GitHub
#3740 (comment).

@sultano
Copy link

@sultano sultano commented Oct 14, 2015

@adamcstephens @benh57 It would seem @l0b0 may have a valid point. I agree the intended Puppet 4 way would be to use directory environments instead of dynamic environments.

Starting with Puppet 3.6, Directory Environments started taking over from Dynamic Environments as Puppet’s mechanism for serving different versions of modules and code. In Puppet 4, they’re the default and other environment support is gone.

Source: Directory Environments Replace Config File Environments

I just fail to see why the environment needs to be specified when using puppet apply

Puppet apply does not use the manifest from an environment; it always uses the manifest given on the CLI.

Source: Directories: The Main Manifest(s)

So Vagrantfile's without the environment specified in a masterless setup should still work as expected?

@sultano
Copy link

@sultano sultano commented Oct 14, 2015

As a workaround, I've set the following in my Vagrantfile to force environments mode without having to change the folder structure.

puppet.environment = "production"
puppet.environment_path = "../../"
@benh57
Copy link
Contributor

@benh57 benh57 commented Oct 14, 2015

Suleman -- I chose to have it default to using the old system, so that pre
existing vagrantfiles + machines would continue to work.

Vagrant currently has no mechanism to detect your puppet version.

If you're on the older puppet versions, no changes need be made. Changes to
vagrantfiles are only required if you upgrade puppet. I don't consider
specifying the environment as you are doing a workaround, rather it's the
intended behavior.

Ideal would probably be if the mode flipped automatically depending on your
installed puppet version -- anyone is free to implement that.. I just
implemented this based on my needs, well after posting the proposal here.
I'm not a core vagrant developer.

-Ben

On Wed, Oct 14, 2015 at 2:19 AM, Suleman Chikhalia <notifications@github.com

wrote:

As a workaround, I've set the following in my Vagrantfile to force
environments mode without having to change the folder structure.

puppet.environment = "production"
puppet.environment_path = "../../"


Reply to this email directly or view it on GitHub
#3740 (comment).

@ferventcoder
Copy link
Author

@ferventcoder ferventcoder commented Oct 14, 2015

Vagrant prolly could query Puppet to see what version it is and adjust accordingly.

@martijn
Copy link

@martijn martijn commented Nov 3, 2015

Ok I missed the whole environments / Puppet 4 thing (should've read the changelog). I'm going to try it out but I assume that fixes the issue. Thanks for clarifying @benh57

@iainhallam
Copy link

@iainhallam iainhallam commented Nov 2, 2016

The documentation currently says (https://www.vagrantup.com/docs/provisioning/puppet_apply.html):

If you are using Puppet 4 or higher, you can provision using Puppet Environments by specifying the name of the environment and the path on the local disk to the environment files

I read this and thought that since I was using only a single manifest, I wouldn't use the environments configuration as it's just extra things to do, when all I want is to apply a single file. If Vagrant is actually using environment configuration as a flag to decide whether to use Puppet 4-style calling, then this needs to be changed to "must" or at least "should".

An alternative would be to add a "manifest" configuration that also makes Vagrant use v4-style calls to Puppet but can take a path and filename together.

@hashibot
Copy link

@hashibot hashibot bot commented Apr 3, 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.

@hashibot hashibot bot locked and limited conversation to collaborators Apr 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet