Puppet users - Apr 2012 - 2 package resources for the same package installation in two differents modules caused errors

Hello,

We had the following situation where including two classes that were
ensuring the installation of the same package "php5-imagick" and it
was causing an error indicating that two ressources of the same name
are forbidden (sorry, I don''t have the exact message error since we
fixed quickly the error).

Since we are newbies in puppet, we would like to understand what this
error meant:
does it mean that all the package resource ensuring the installation
of a package need to have a unique resource name ?
Or maybe have we done something wrong in our usage of puppet ?

Below, the code causing the error and how we fixed it.

Thanks in advance for your feebacks.

Best regards,
Christophe

Code causing the error:

/etc/puppet/modules/apache/manifests/init.pp

class apache::install {
  ...
  package { [ "php5", "php5-cli", "php5-gd",
"php5-imagick", "php5-
mysql", "phpmyadmin", "mysql-client" ]:
	ensure => installed,
  }
  ...
}

/etc/puppet/modules/cms/manifests/init.pp

class cms::installpackage {
  ...
  package { ''php5-imagick'':
    name => ''php5-imagick'',
    ensure => ''installed'',
  }
  ...
}

In order to fix the error, we prefixed the resource in
cms::installpackage class with cms_

package { ''cms_php5-imagick'':
    name => ''php5-imagick'',
    ensure => ''installed'',
}

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 3, 2012 at 3:33 PM, Christophe L <cl.subscription@gmail.com>
wrote:
> Hello,
>
> We had the following situation where including two classes that were
> ensuring the installation of the same package "php5-imagick" and
it
> was causing an error indicating that two ressources of the same name
> are forbidden (sorry, I don''t have the exact message error since
we
> fixed quickly the error).
>
By the nature of the Puppet''s language, resources must have a unique
title and must have only one definition.

Quoting http://docs.puppetlabs.com/guides/language_guide.html#resources:

"The field before the colon is the resource’s title, which must be
unique and can be used to refer to the resource in other parts of the
Puppet configuration."
> Code causing the error:
>
> /etc/puppet/modules/apache/manifests/init.pp
>
> class apache::install {
>  ...
>  package { [ "php5", "php5-cli", "php5-gd",
"php5-imagick", "php5-
> mysql", "phpmyadmin", "mysql-client" ]:
>        ensure => installed,
>  }
The line above is just a shortcut to this something like this:

package {"php5": .... }
package {"php5-cli": .... }
package {"php5-imagick": .... }

So when Puppet compiles all your manifests, there can be only one
php5-imagick, in your case.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hello,

Thanks for your answer.

I understand the restriction about resource name uniqueness, but I
don''t understand the practical usage of it on the package resources.

Let''s say there is two modules totally different, written by two
different developpers, but both depending on the same debian
package :
the two developper wills use the simplified syntax of the package
resource such package { "MODULE_NAME" : ensure => installed }, like
we
can see it on usual puppet sample on internet.

Then, when an administrator will include the two modules, it will fail
because the same package is defined twice, even if the description of
the resource is exactly the same.

It doesn''t sound as a normal behavior to me, unless if a best practice
is to never use the simplified syntax for package resource ?

Or is there an other best practice for avoiding this situation ?

Thanks in advance for your answers.

Best regards.
Christophe


On 4 avr, 00:15, Miguel Di Ciurcio Filho <miguel.fi...@gmail.com>
wrote:
> On Tue, Apr 3, 2012 at 3:33 PM, Christophe L
<cl.subscript...@gmail.com> wrote:
> > Hello,
>
> > We had the following situation where including two classes that were
> > ensuring the installation of the same package "php5-imagick"
and it
> > was causing an error indicating that two ressources of the same name
> > are forbidden (sorry, I don''t have the exact message error
since we
> > fixed quickly the error).
>
> By the nature of the Puppet''s language, resources must have a
unique
> title and must have only one definition.
>
> Quotinghttp://docs.puppetlabs.com/guides/language_guide.html#resources:
>
> "The field before the colon is the resource’s title, which must be
> unique and can be used to refer to the resource in other parts of the
> Puppet configuration."
>
> > Code causing the error:
>
> > /etc/puppet/modules/apache/manifests/init.pp
>
> > class apache::install {
> >  ...
> >  package { [ "php5", "php5-cli",
"php5-gd", "php5-imagick", "php5-
> > mysql", "phpmyadmin", "mysql-client" ]:
> >        ensure => installed,
> >  }
>
> The line above is just a shortcut to this something like this:
>
> package {"php5": .... }
> package {"php5-cli": .... }
> package {"php5-imagick": .... }
>
> So when Puppet compiles all your manifests, there can be only one
> php5-imagick, in your case.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

The best way to overcome the problem you''re experiencing, is to use
virtual
resources 

http://docs.puppetlabs.com/guides/virtual_resources.html

So, for example, you would have a class that declares the resources:

class php_v_packages {

    @package { [ "php5", "php5-cli", "php5-gd",
"php5-imagick", "php5-
        mysql", "phpmyadmin", "mysql-client" ]: 
        ensure => installed, 
    } 

}

and when you need to use those virtual packages, include that class, and 
realize the resources:

class apache::install { 

    include php_v_packages
    realize Package [ [ php5"], [php5-cli], [php5-gd], [php5-imagick]]

}

class cms::installpackage { 

    include php_v_packages
    realize Package [php5-imagick]

}

That should do the trick :)

Cheers,
Andrew

On Thursday, April 5, 2012 12:11:40 PM UTC+1, Christophe L
wrote:
>
> Hello, 
>
> Thanks for your answer. 
>
> I understand the restriction about resource name uniqueness, but I 
> don''t understand the practical usage of it on the package
resources.
>
> Let''s say there is two modules totally different, written by two 
> different developpers, but both depending on the same debian 
> package : 
> the two developper wills use the simplified syntax of the package 
> resource such package { "MODULE_NAME" : ensure => installed },
like we
> can see it on usual puppet sample on internet. 
>
> Then, when an administrator will include the two modules, it will fail 
> because the same package is defined twice, even if the description of 
> the resource is exactly the same. 
>
> It doesn''t sound as a normal behavior to me, unless if a best
practice
> is to never use the simplified syntax for package resource ? 
>
> Or is there an other best practice for avoiding this situation ? 
>
> Thanks in advance for your answers. 
>
> Best regards. 
> Christophe 
>
>
> On 4 avr, 00:15, Miguel Di Ciurcio Filho <miguel.fi...@gmail.com> 
> wrote: 
> > On Tue, Apr 3, 2012 at 3:33 PM, Christophe L
<cl.subscript...@gmail.com>
> wrote: 
> > > Hello, 
> > 
> > > We had the following situation where including two classes that
were
> > > ensuring the installation of the same package
"php5-imagick" and it
> > > was causing an error indicating that two ressources of the same
name
> > > are forbidden (sorry, I don''t have the exact message
error since we
> > > fixed quickly the error). 
> > 
> > By the nature of the Puppet''s language, resources must have a
unique
> > title and must have only one definition. 
> > 
> >
Quotinghttp://docs.puppetlabs.com/guides/language_guide.html#resources:
> > 
> > "The field before the colon is the resource’s title, which must
be
> > unique and can be used to refer to the resource in other parts of the 
> > Puppet configuration." 
> > 
> > > Code causing the error: 
> > 
> > > /etc/puppet/modules/apache/manifests/init.pp 
> > 
> > > class apache::install { 
> > >  ... 
> > >  package { [ "php5", "php5-cli",
"php5-gd", "php5-imagick", "php5-
> > > mysql", "phpmyadmin", "mysql-client" ]: 
> > >        ensure => installed, 
> > >  } 
> > 
> > The line above is just a shortcut to this something like this: 
> > 
> > package {"php5": .... } 
> > package {"php5-cli": .... } 
> > package {"php5-imagick": .... } 
> > 
> > So when Puppet compiles all your manifests, there can be only one 
> > php5-imagick, in your case.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/fnts8JOMwnIJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 5, 6:11 am, Christophe L <cl.subscript...@gmail.com>
wrote:
> Hello,
>
> Thanks for your answer.
>
> I understand the restriction about resource name uniqueness, but I
> don''t understand the practical usage of it on the package
resources.
>
> Let''s say there is two modules totally different, written by two
> different developpers, but both depending on the same debian
> package :
> the two developper wills use the simplified syntax of the package
> resource such package { "MODULE_NAME" : ensure => installed },
like we
> can see it on usual puppet sample on internet.
>
> Then, when an administrator will include the two modules, it will fail
> because the same package is defined twice, even if the description of
> the resource is exactly the same.
>
> It doesn''t sound as a normal behavior to me, unless if a best
practice
> is to never use the simplified syntax for package resource ?
>
> Or is there an other best practice for avoiding this situation ?

Expanding somewhat on Andrew''s response:

From a conceptual perspective, if two separate and independent modules
both require the same package, then clearly it is incorrect to model
that package as belonging to or being the responsibility of either
module.  It is a more fundamental resource than either module
represents, else you would not have such a conflict in the first
place.

The correct solution, both conceptually and practically, is to manage
the package via a separate module that both of the others rely upon.
In your particular case, it looks like it would be very natural to
create and use a "php" or "php5" module to manage all the
PHP
packages.  Your "apache" and "cms" modules would then both
depend on
the new "php" module to ensure that the needed packages were
installed.

At the manifest level, suppose you put all the PHP package
declarations in class "php::packages".  Then both
"apache::install"
and "cms::installpackage" would put this line at the beginning of
their bodies:

include "php::packages"

IMPORTANT: Puppet''s ''include'' function is *not*
analogous to the C
preprocessor''s #include directive: it does not interpolate anything.
It''s much closer to Python''s ''import''
statement, which makes Python
modules visible to other Python modules.

If you don''t necessarily need all of the PHP packages for every PHP
user, as it appears may be the case, then you can additionally declare
the PHP packages virtually in "php::packages".  Then, after
''include''ing php::packages, your other modules would also
''realize''
the packages they need.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

What I normally do is I create a virtual @package resource which installs 
php5 for example within say "apache" class and then I realize the
virtual
resource within the same "apache" class.

Please, if you intend to write generic and reusable modules so other people 
can use, STOP putting hardcoded dependencies in your modules.

Either write in documentation that it depends on an abstract resource, for 
instance a mysql database and make it configurable so you can pass db_name, 
db_host, etc to your "apache" class. Or create virtual resources and 
realize them within the same class - works great for packages and maybe 
other resource types.


On Tuesday, 3 April 2012 19:33:32 UTC+1, Christophe L
wrote:
>
> Hello, 
>
> We had the following situation where including two classes that were 
> ensuring the installation of the same package "php5-imagick" and
it
> was causing an error indicating that two ressources of the same name 
> are forbidden (sorry, I don''t have the exact message error since
we
> fixed quickly the error). 
>
> Since we are newbies in puppet, we would like to understand what this 
> error meant: 
> does it mean that all the package resource ensuring the installation 
> of a package need to have a unique resource name ? 
> Or maybe have we done something wrong in our usage of puppet ? 
>
> Below, the code causing the error and how we fixed it. 
>
> Thanks in advance for your feebacks. 
>
> Best regards, 
> Christophe 
>
> Code causing the error: 
>
> /etc/puppet/modules/apache/manifests/init.pp 
>
> class apache::install { 
>   ... 
>   package { [ "php5", "php5-cli", "php5-gd",
"php5-imagick", "php5-
> mysql", "phpmyadmin", "mysql-client" ]: 
>         ensure => installed, 
>   } 
>   ... 
> } 
>
> /etc/puppet/modules/cms/manifests/init.pp 
>
> class cms::installpackage { 
>   ... 
>   package { ''php5-imagick'': 
>     name => ''php5-imagick'', 
>     ensure => ''installed'', 
>   } 
>   ... 
> } 
>
> In order to fix the error, we prefixed the resource in 
> cms::installpackage class with cms_ 
>
> package { ''cms_php5-imagick'': 
>     name => ''php5-imagick'', 
>     ensure => ''installed'', 
> }
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/taR8nQd_iDMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tuesday, November 6, 2012 12:31:16 PM UTC-6, Vaidas Jablonskis
wrote:
>
> What I normally do is I create a virtual @package resource which installs 
> php5 for example within say "apache" class and then I realize the
virtual
> resource within the same "apache" class.
>
> Please, if you intend to write generic and reusable modules so other 
> people can use, STOP putting hardcoded dependencies in your modules.
>
> Either write in documentation that it depends on an abstract resource, for 
> instance a mysql database and make it configurable so you can pass db_name,
> db_host, etc to your "apache" class. Or create virtual resources
and
> realize them within the same class - works great for packages and maybe 
> other resource types.
>
>
If only it were that easy.  Cross-module dependencies are a particularly 
tricky issue for all past and present Puppet versions.  We have had some 
interesting discussions on that topic here, with some possibly-useful ideas 
arising from them, but none of that has made it into the codebase yet.

If you write all your own modules then you can probably keep the problem 
under control, but if you rely on others'' modules then you simply have
to
be prepared to make local modifications to address compatibility problems.  
Good module documentation is helpful for that, but there is no 
documentation or coding practice that can solve the problem under the 
current DSL.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/FuNKiZK0t_kJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.