[Puppet Users] Re: [puppet apply --ordering = manifest] is not working as expected
On Friday, November 21, 2014 4:33:48 PM UTC-6, Eric Sorenson wrote:
Hi Kyle --
On Friday, November 21, 2014 1:46:19 PM UTC-8, Kyle Purdon wrote:
TL:DR Using the --ordering = manifest option does not seem to apply to
module commands.
Using this parameter I would expect puppet to apply my manifest (site.pp)
in the order it is written (script like execution).
I would advise you to avoid that thought process. Puppet is not a script
engine, and puppet manifests are not scripts. Wishing that they were, and
using the --ordering = manifest option to try to make it so, is likely to
lead to grief (as indeed it seems to have done in this case). I've never
much seen the point of that option, actually. People who are clueful
enough to know about it and to know why it might be useful are also clueful
enough to write their manifests so that they don't rely on it. It is
better for your manifest set to be self-contained than for its correctness
to depend on the options with which puppet is run.
Note, too, that the 'ordering' parameter is a *fallback*, not absolute. It
affects only the relative order of resources whose relative order is not
otherwise directed.
It appears to do so for everything except module commands. The following
commands get executed after all done even though they are commands in the
middle of the manifest. Both are module commands.
I see it's going to be some work to break you of script-think. Those are
*not* commands. Puppet DSL doesn't have any commands. In fact, nothing in
your manifests is executable in the sense that you are thinking.
rbenv::plugin { sstephenson/ruby-build: latest = true }
rbenv::build { $EDB_RUBY_VERSION: global = true }
nsidc_nfs::sharemount { /disks/backups: project = backups, options
= ro }
Those are all resource declarations. Specifically, declarations of
resources of defined types, whose definitions happen to be in modules.
Hmm, I think you need to use the 'contain' function in conjunction with
the ordering so that these classes work the way you expect.
Nope, because they are not classes. The 'contain' function (and the need
for it) does not apply to them. Moreover, the manifest provided contains
only top-level declarations. Containment is only applicable to class
contexts.
That may, in fact, be the key issue here, because everything else aside, I
don't see any reason why Puppet should not behave as Kyle expects. It may
be that the --ordering = manifest option does not work correctly for
declarations at top scope. I would file a bug report.
The good thing is that there are workarounds available, which generally
boil down to producing a superior manifest. Recommendations (choose ALL of
the following):
1. Don't sweat the relative order in which resources are applied where
it doesn't actually matter. For example, if neither postgres nor SQLite is
initially installed, it surely doesn't matter which is installed first.
2. Where it *does* matter that one resource is managed before another,
express it in your manifests. That's what the chaining arrows and the
'require' family of metaparameters are for. (See the resource ordering
docs https://docs.puppetlabs.com/learning/ordering.html.)
3. Organize your code into classes, and keep top-scope declarations to a
minimum.
# INSTALL EMACS BECAUSE IT'S THE BEST EDITOR
notify { installing emacs: }
if str2bool($INSTALL_EMACS) {
package { [emacs24]: ensure = present }
}
Aha, here's your real problem :)
But I think Eric's onto something there. :)
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f01bb402-fe76-434a-b4b8-4d41f7c66934%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [puppet apply --ordering = manifest] is not working as expected
Eric,
Thanks for the response. I spent the weekend looking into puppet class
containment, what a joy!
I am still a bit unclear on applying contain in my situation.
Should I create a wrapper class around my entire manifest and contain the
few things within that? How would I apply this to the rbenv subclasses?
Thanks!
On Friday, November 21, 2014 3:33:48 PM UTC-7, Eric Sorenson wrote:
Hi Kyle --
On Friday, November 21, 2014 1:46:19 PM UTC-8, Kyle Purdon wrote:
TL:DR Using the --ordering = manifest option does not seem to apply to
module commands.
Using this parameter I would expect puppet to apply my manifest (site.pp)
in the order it is written (script like execution).
It appears to do so for everything except module commands. The following
commands get executed after all done even though they are commands in the
middle of the manifest. Both are module commands.
rbenv::plugin { sstephenson/ruby-build: latest = true }
rbenv::build { $EDB_RUBY_VERSION: global = true }
nsidc_nfs::sharemount { /disks/backups: project = backups, options
= ro }
Hmm, I think you need to use the 'contain' function in conjunction with
the ordering so that these classes work the way you expect.
https://docs.puppetlabs.com/references/3.7.latest/function.html#contain
There's a great blog post by Zachary Stern about this:
http://puppetlabs.com/blog/class-containment-puppet
# INSTALL EMACS BECAUSE IT'S THE BEST EDITOR
notify { installing emacs: }
if str2bool($INSTALL_EMACS) {
package { [emacs24]: ensure = present }
}
Aha, here's your real problem :)
--eric0
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/0f52fd8f-de73-4ab1-a6d2-fa4341daa87f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [puppet apply --ordering = manifest] is not working as expected
Eric John!
Emacs is the best! Get over it! =)
Anyway,
I do think John is correct, I really was trying to avoid what is clearly
the Puppet way of things by treating resources as executable things and
trying to order them as such. I think the idea of organizing the manifest
into classes and applying ordering to those classes (not using --ordering)
might be the way to go.
John, do you think this is actually a bug-worthy event that i'm seeing?
Thanks all!
On Monday, November 24, 2014 7:56:34 AM UTC-7, jcbollinger wrote:
On Friday, November 21, 2014 4:33:48 PM UTC-6, Eric Sorenson wrote:
Hi Kyle --
On Friday, November 21, 2014 1:46:19 PM UTC-8, Kyle Purdon wrote:
TL:DR Using the --ordering = manifest option does not seem to apply to
module commands.
Using this parameter I would expect puppet to apply my manifest
(site.pp) in the order it is written (script like execution).
I would advise you to avoid that thought process. Puppet is not a script
engine, and puppet manifests are not scripts. Wishing that they were, and
using the --ordering = manifest option to try to make it so, is likely to
lead to grief (as indeed it seems to have done in this case). I've never
much seen the point of that option, actually. People who are clueful
enough to know about it and to know why it might be useful are also clueful
enough to write their manifests so that they don't rely on it. It is
better for your manifest set to be self-contained than for its correctness
to depend on the options with which puppet is run.
Note, too, that the 'ordering' parameter is a *fallback*, not absolute.
It affects only the relative order of resources whose relative order is not
otherwise directed.
It appears to do so for everything except module commands. The following
commands get executed after all done even though they are commands in the
middle of the manifest. Both are module commands.
I see it's going to be some work to break you of script-think. Those are
*not* commands. Puppet DSL doesn't have any commands. In fact, nothing
in your manifests is executable in the sense that you are thinking.
rbenv::plugin { sstephenson/ruby-build: latest = true }
rbenv::build { $EDB_RUBY_VERSION: global = true }
nsidc_nfs::sharemount { /disks/backups: project = backups, options
= ro }
Those are all resource declarations. Specifically, declarations of
resources of defined types, whose definitions happen to be in modules.
Hmm, I think you need to use the 'contain' function in conjunction with
the ordering so that these classes work the way you expect.
Nope, because they are not classes. The 'contain' function (and the need
for it) does not apply to them. Moreover, the manifest provided contains
only top-level declarations. Containment is only applicable to class
contexts.
That may, in fact, be the key issue here, because everything else aside, I
don't see any reason why Puppet should not behave as Kyle expects. It may
be that the --ordering = manifest option does not work correctly for
declarations at top scope. I would file a bug report.
The good thing is that there are workarounds available, which generally
boil down to producing a superior manifest. Recommendations (choose ALL of
the following):
1. Don't sweat the relative order in which resources are applied where
it doesn't actually matter. For example, if neither postgres nor SQLite
is
initially installed, it surely doesn't matter which is installed first.
2. Where it *does* matter that one resource is managed before another,
express it in your manifests. That's what the chaining arrows and the
'require' family of metaparameters are for. (See the resource
ordering docs https://docs.puppetlabs.com/learning/ordering.html.)
3. Organize your code into classes, and keep top-scope declarations to
a minimum.
# INSTALL EMACS BECAUSE IT'S THE BEST EDITOR
notify { installing emacs: }
if str2bool($INSTALL_EMACS) {
package { [emacs24]: ensure = present }
}
Aha, here's your real problem :)
But I think Eric's onto something there. :)
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/076692ef-2d19-4ddc-b896-39d49e7f0845%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: [puppet apply --ordering = manifest] is not working as expected
Hi, On 11/24/2014 04:04 PM, Kyle Purdon wrote: Eric John! Emacs is the best! Get over it! =) Emacs is nice, but I prefer Debian. (And no, I'm likely younger than this joke.) On Monday, November 24, 2014 7:56:34 AM UTC-7, jcbollinger wrote: Nope, because they are not classes. The 'contain' function (and the need for it) does not apply to them. Moreover, the manifest provided contains only top-level declarations. Containment is only applicable to class contexts. Yeah, but concerning the irritation about top level declarations apparently not being ordered: 1. I don't believe this is a thing, seeing as the manifest ordering code is realy, really simple. But sure, you never know :) 2. These defined types might well include classes, which will not be ordered by just manifest-ordering the defined type instances, but *will* get ordered if they are contained instead of defined. But don't go ahead and blindly replace include with contain. There is even more grief down that road. Cheers, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/54734AE0.2040901%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [puppet apply --ordering = manifest] is not working as expected
Here is my Vagrantfile if that helps:
Vagrant.configure(2) do |config|
config.vm.provision :shell, :inline =
cd /vagrant/puppet/librarian;
librarian-puppet clean --verbose; librarian-puppet update --verbose
config.vm.provision :shell, :inline = puppet apply --ordering=manifest
--modulepath=/vagrant/puppet/librarian/modules:/vagrant/puppet/modules
/vagrant/puppet/manifests
end
On Friday, November 21, 2014 2:46:19 PM UTC-7, Kyle Purdon wrote:
TL:DR Using the --ordering = manifest option does not seem to apply to
module commands.
Using this parameter I would expect puppet to apply my manifest (site.pp)
in the order it is written (script like execution).
It appears to do so for everything except module commands. The following
commands get executed after all done even though they are commands in the
middle of the manifest. Both are module commands.
rbenv::plugin { sstephenson/ruby-build: latest = true }
rbenv::build { $EDB_RUBY_VERSION: global = true }
nsidc_nfs::sharemount { /disks/backups: project = backups, options =
ro }
Below is my manifest for reference.
include nsidc_nfs
# ==
# EDB VM PUPPET CONFIGURATION
# ==
# TODO: REPLACE WITH YAML FILE CONFIGS
# USER VARIABLES
$EDB_RUBY_VERSION = 1.9.3-p194
$INSTALL_EMACS = false
$FULL_DATABASE_RECREATE = true
$EDB_DATABASE_USERNAME = kpurdon
# SET GLOBAL EXEC PATH
Exec { path = [ /usr/local/rbenv/shims/, /usr/local/rbenv/bin/,
/usr/local/sbin/, /usr/local/bin/, /usr/sbin/, /usr/bin/, /sbin/,
/bin/ ] }
# INSTALL EMACS BECAUSE IT'S THE BEST EDITOR
notify { installing emacs: }
if str2bool($INSTALL_EMACS) {
package { [emacs24]: ensure = present }
}
# INSTALL RBENV+RUBY-BUILD AND EDB RUBY VERSION
# this is using jdowning/rbenv
notify { installing rbenv: }
class { rbenv: latest = true }
rbenv::plugin { sstephenson/ruby-build: latest = true }
rbenv::build { $EDB_RUBY_VERSION: global = true }
# INSTALL POSTGRESQL+LIBPQDEV
notify { installing postgres: }
package { [postgresql-9.3, libpq-dev]: ensure = present }
# INSTALL SQLITE+SPATIALITE
notify { installing sqlite: }
package { [sqlite3, libsqlite3-dev]: ensure = present }
package { [spatialite-bin, libspatialite5, libspatialite-dev]:
ensure = present }
# INSTALL PROJECT GEMS
notify { installing edb gems: }
exec { install edb project gems:
cwd = /vagrant,
command = bundle install --path=.gems
}
# MOUNT DISKS/BACKUPS FOR EDB BACKUP ACESS
# /disks/backups/databases/mukluk/pgsql/edb_prod_snapshot_with_granules.DMP
notify { mounting disks: }
nsidc_nfs::sharemount { /disks/backups: project = backups, options =
ro }
notify { setting database user: }
file_line { export database user env:
path = /home/vagrant/.bashrc,
line = export DATABASE_ENV=${EDB_DATABASE_USERNAME}
}
notify { recreating the database: }
if str2bool($FULL_DATABASE_RECREATE) {
#exec { rake recreate database full:
# cwd - /vagrant,
# command = rake db:recreate_db['full']
#}
}
notify { all done: }
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2d5b37e5-b56d-4708-9b9c-d66b43f18c12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [puppet apply --ordering = manifest] is not working as expected
Hi Kyle --
On Friday, November 21, 2014 1:46:19 PM UTC-8, Kyle Purdon wrote:
TL:DR Using the --ordering = manifest option does not seem to apply to
module commands.
Using this parameter I would expect puppet to apply my manifest (site.pp)
in the order it is written (script like execution).
It appears to do so for everything except module commands. The following
commands get executed after all done even though they are commands in the
middle of the manifest. Both are module commands.
rbenv::plugin { sstephenson/ruby-build: latest = true }
rbenv::build { $EDB_RUBY_VERSION: global = true }
nsidc_nfs::sharemount { /disks/backups: project = backups, options =
ro }
Hmm, I think you need to use the 'contain' function in conjunction with the
ordering so that these classes work the way you expect.
https://docs.puppetlabs.com/references/3.7.latest/function.html#contain
There's a great blog post by Zachary Stern about
this: http://puppetlabs.com/blog/class-containment-puppet
# INSTALL EMACS BECAUSE IT'S THE BEST EDITOR
notify { installing emacs: }
if str2bool($INSTALL_EMACS) {
package { [emacs24]: ensure = present }
}
Aha, here's your real problem :)
--eric0
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/afd4ce04-ae12-46d3-b1c2-dc023499319b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
