I have a puppet program that I'm trying to use stages in to better manage timing, but when I try that, nothing happens. I then tried to just use a dependency chain, but that throws back this error:
Error: Could not apply complete catalog: Found 1 dependency cycle:
(Anchor[apt::ppa::ppa:saltstack/salt] => Apt::Ppa[ppa:saltstack/salt] => class[Pp_package_manager] => Class[User_manager] => User_manager::User[coder] => User[coder] => File[/etc/default/perfectpitch] => Class[Pp_package_manager])
I'm trying to understand what this error is telling me, but the => signs are confusing the heck out of me. I also tried to open up the .dot file using the --graph flag, but that just confuses me as well. I'd love a guiedhttps://gist.github.com/supereman16/1ff46d6fbb1c7ac9b709.
I'd love a guide on how to interpret these and possibly some help with where the problem actually is. Any help will be greatly appreciated in helping me understand this error, and the steps I should take to find the problem and fix it. Thanks in advance!
Please read this article about relations and ordering in puppet.
In summary.
Puppet is a declarative language, where you describe a desired state of your system (not how to achieve it). So when it compiles manifests code to catalogue, it tries to establish order in which resources should be realized achieve desired state (it creates graph of dependencies).
E.g you cannot run mysql server unless you install mysql package.
Generally puppet properly solves relationships between resources. But sometimes it needs help. For each resource you can manually define relationship between other resources, using before, require, notify, subscribe metaparameters. Unfortunately, using these metaparameters you can easily create a cycle of dependencies.
E.g
file { a: require => File['b'] }
file { b: require => File['c'] }
file { c: require => File['a'] }
Such declaration of resources will create a cycle of dependencies causing compilation error similar to what you have.
It the message you provide, a => b means do resource a before resource b.
You got a cycle of dependencies: ...=> class[Pp_package_manager] => ... Class[Pp_package_manager].
I'm guessing you have defined relationships File[/etc/default/perfectpitch] => Class[Pp_package_manager] and class[Pp_package_manager] => Class[User_manager] , which causes an error.
Related
First, sorry for asking basic and quite silly questions.
I'm very newbie and do not have much experience in this kind of operation.
I have read many documents from official site, tutorialspoint(gave me basic concepts of how puppet work) site and else but still confused and don't know where to start.
Since I wanted to install Azure to all slave nodes, I think I have to create classes like
class packages {
# the first, most obvious solution is
package { 'screen': ensure => 'installed' }
package { 'strace': ensure => 'installed' }
package { 'sudo': ensure => 'installed' }
# you can use a global package parameter
Package { ensure => 'installed' }
package { 'screen': }
package { 'strace': }
package { 'sudo': }
# you can specify the packages in an array ...
$enhancers = [ 'screen', 'strace', 'sudo' ]
package { $enhancers: ensure => 'installed' }
# ... and even combine it a global package parameter
Package { ensure => 'installed' }
$enhancers = [ 'screen', 'strace', 'sudo' ]
package { $enhancers: }
}
cr: https://www.puppetcookbook.com/posts/install-multiple-packages.html
But hey! where should I put that code to ?, How can I execute that? they do not tell me T-T
I really appreciate for all your kindness and your answers
Thanks
Edited on 26th Mar 2019
Thanks for all the comments, I've read for the architecture and be able to create a class now.
Note that The Puppet Cookbook goes back to the days of Puppet 3. It can still be useful, but it predates modern language features like iteration and data types, and no longer aligns with modern best practices.
Nowadays, I rarely see packages grouped into a class like this by the way. Often, packages are externalised in Hiera as data and read into a class, perhaps a "configure" or "install" class, via a packages parameter. (Not that I'm suggesting there's anything wrong with having a packages class.)
To the main part of your question:
But hey! where should I put that code to ?, How can I execute that? they do not tell me T-T
To learn more about how to organise your classes, you need to learn about the Roles and Profiles pattern.
UPDATE: As pointed out in the comments, you may be confused about more basic things than how to organise your classes. At this point, I should say that Stack Overflow is a site for asking specific questions that have a specific answer.
Do have a look at this page here. My suggestion is to follow the advice in there and join the Puppet Community Slack. People in that forum will be glad to help you get started and answer your questions in real time.
I'm trying to set up a Puppet cron job with the following structure:
file { '/usr/local/sbin/file.py':
mode => '0755',
source => 'puppet:///modules/file.py',
require => File['/usr/local/sbin']
}
cron { "cronjob":
require => "ALL_THE_FILES_ABOVE"
command => "...command_to_run_script..."
minute => '*/1'
}
All of the above is in one file run_script.pp. I'm wondering how I can code the require => "ALL_THE_FILES_ABOVE" part.
Thanks!
Based on the information provided in your question, I am going to make the assumption that the contents of run_script.pp is many file resources and the listed cron resource. You state that you want the cron resource there to require all of the file resources in that class. Based on this, here is a clean and efficient solution.
There are a few complicated/advanced ways to arrive at a clean and efficient solution, but the easiest to understand is to use a resource default: https://puppet.com/docs/puppet/5.3/lang_defaults.html
With this, we can establish attribute/value pair defaults for all file resources contained in that scope. This would make it easier to use the before metaparameter on the file resources instead: https://puppet.com/docs/puppet/5.3/metaparameter.html#before
This simplifies the solution to a one-liner in your class:
File { before => Cron['cronjob'] }
Note there will be a caveat to this method, which is that if you are declaring, requiring, or containing a class within this manifest, then this default could be expanded to that "area of effect" and cause a circular dependency. In that case, you should use a per-expression resource default attribute: https://puppet.com/docs/puppet/5.3/lang_resources_advanced.html#per-expression-default-attributes
You can use a multiple require
file{'path/foo':}
file{'path/bar':}
file{'~/foobar':
require => [ File['path/foo'], File['path/bar'] ]
}
or you can use the ordering arrow
-> (ordering arrow; a hyphen and a greater-than sign) — Applies the resource on the left before the resource on the right.
file{'path/foo':} ->
file{'path/bar':} ->
file{'~/foobar':}
Here is more information about relationships and ordering in Puppet
Lets say I want to define a set of resources that have dependencies on each other, and the dependent resources should reuse parameters from their ancestors. Something like this:
server { 'my_server':
path => '/path/to/server/root',
...
}
server_module { 'my_module':
server => Server['my_server'],
...
}
The server_module resource both depends on my_server, but also wants to reuse the configuration of it, in this case the path where the server is installed. stdlib has functions for doing this, specifically getparam().
Is this the "puppet" way to handle this, or is there a better way to have this kind of dependency?
I don't think there's a standard "puppet way" to do this. If you can get it done using the stdlib and you're happy with it, then by all means do it that way.
Personally, if I have a couple defined resources that both need the same data I'll do one of the follow:
1) Have a manifest that creates both resources and passes the data both need via parameters. The manifest will have access to all data both resources need, whether shared or not.
2) Have both defined resources look up the data they need in Hiera.
I've been leaning more towards #2 lately.
Dependency is only a matter of declaring it. So your server_module resource would have a "require => Server['my_server']" parameter --- or the server resource would have a "before => Server_module['my_module']".
I have encounter really weird behaviour which goes against what I have learned, tutorial says etc. So I would be glad if someone could explain why that is happening.
I have a role module which is made up of composition of profiles (role-profile pattern). My role consists:
class role::lab_prg_c2_dn inherits lab_prg_c2 {
class { 'profile::cluster_data_node':
namenode_fqdn => $role::lab_prg_c2::namenode_fqdn,
secondarynamenode_fqdn => $role::lab_prg_c2::secondarynamenode_fqdn,
}
->
class{'bigdatasolution':}
}
First class installs technology and second one installs our components and items which are build on top of technology. Hence the technology need to be installed first, thats the reason for "->" dependency. However this seems to me doesn't work correctly. As components from class 'bigdatasolution' are installed somewhere before the class profile::cluster_data_node finishes.
I tried to use require => Class['profile::cluster_data_node'] but that doesn't make any difference!
The content of class{'bigdatasolution':} :
class bigdatasolution {
$hdfs_default_conf = '/usr/local/hadoop.hdfs.conf'
$hbase_default_conf = '/usr/local/hadoop.hbase.conf'
include symlinks
include bdjar
}
Symlinks - create symlinks for the configuration installed in class profile::cluster_data_node and are not directly managed - it will be presented when actually specified package get installed.
bdjar - add our jar to a technology library so content is as follows:
class bigdatasolution::bdjar {
file { "/usr/lib/hadoop/lib/bigdata-properties.jar":
ensure => present,
mode => 0644,
group => 'root',
owner => 'root',
source => "puppet:///modules/bigdatasolution/bigdata-properties.jar"
}
}
I even tried to put require => "technologycalClass" here but that doesn't help either.
Can someone please help me understand what's wrong and how that should be solved properly?
I Using puppet 3 and ordering is specified explicetly - so no arbitrary ordering set by puppet should happen.
Thanks
If your 'profile::cluster_data_node' class 'includes' other classes/modules they will have no dependency ordering with the 'bigdatasolution' class.
I see you actually do include symlinks and bdjar. Basically every piece of ordering you want to have in puppet, you need to write explicitly.
Here you should replace the include statements with require, that way the class cluster_data_node will require the other two modules to complete before it says it has completed. Include is a pretty lose way of importing things in puppet and in my opinion is best to just avoid it and go with explicit require statements instead.
TL;DR: included modules have no transitive ordering; required modules do.
I'm writing some puppet modules and have a package defined in two modules hence get the following error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate definition: Package[gnome-session-fallback] is already defined in file /etc/puppet/modules/vnc4server/manifests/init.pp at line 3; cannot redefine at /etc/puppet/modules/vino/manifests/init.pp:7 on node l
Hence want to ensure that the package has not already been defined but the following does not work:
if ! defined ('gnome-session-fallback') {
package { 'gnome-session-fallback':
ensure => installed,
}
}
Can anyone suggest how to fix this, and on the broader scale, what is the "proper" approach to avoiding clashes such as this in modules?
You are missing Package[] inside defined(). The correct way to do it:
if ! defined(Package['gnome-session-fallback']) {
package { 'gnome-session-fallback':
ensure => installed,
}
}
The cleanest way to do this is to use the ensure_resource function from puppetlabs-stdlib:
ensure_resource('package', 'gnome-session-fallback', {'ensure' => 'present'})
To answer my own question about what the "proper" approach is : This issue is discussed at https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/julAujaVsVk and jcbollenger offers what looks like a "best-practice" solution - resources which are defined multiple times should be moved into their own module and included into the classes on which they depend. I applied this and solved my problem.
This doesn't actually answer why "if !defined" fails however...
One cleaner way (among multiple ways) is to create a virtual package resource and then realize it. You can realize the same virtual package multiple times without error.
#package { 'gnome-session-fallback':
ensure => installed,
}
And then where you need it:
realize( Package[ 'gnome-session-fallback' ] )