Puppet users - May 2012 - Issue: packages with same name, different providers.

Hello,
I''ve just run into an issue I''m not able to solve.

I need to have puppet install both the mysql package through yum, AND
the mysql gem.

Those are the pieces of my config as I''m trying to use it:

package { ''mysql-all'':
        ensure => latest,
         name => ''mysql'',
         provider => yum,
        }

    package { ''gem_mysql'':
            ensure => latest,
            name => ''mysql'',
            provider => gem,
            }

error from puppet agent:

err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot
alias Package[mysql-all] to ["mysql"] at
/etc/puppet/modules/mysql/manifests/init.pp:21; resource ["Package",
"mysql"] already declared at
/etc/puppet/modules/redmine/manifests/dependencies.pp:80 at
/etc/puppet/modules/mysql/manifests/init.pp:21 on node alan.dev.centos6


I must set the name parameter because it''s the one that gets used by
the
package manager, I''ve chosen different names for the resources but it
seems like puppet internally forces creating an alias using the package
name.

I''ve tried manually setting an alias, but nothing changes.

puppetmaster: Debian squeeze, puppet 2.7.14

client: Centos 6 32 bit, puppet 2.7.14.

What should I do?


-- 
Latest blog post: Deploying WAR on Heroku http://t.co/M4krW2Mu
contact me at public@[mysurname].eu

-- 
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 May 3, 10:29 am, Alan Franzoni <mail...@franzoni.eu>
wrote:
> Hello,
> I''ve just run into an issue I''m not able to solve.
>
> I need to have puppet install both the mysql package through yum, AND
> the mysql gem.
>
> Those are the pieces of my config as I''m trying to use it:
>
> package { ''mysql-all'':
>         ensure => latest,
>          name => ''mysql'',
>          provider => yum,
>         }
>
>     package { ''gem_mysql'':
>             ensure => latest,
>             name => ''mysql'',
>             provider => gem,
>             }
>
> error from puppet agent:
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot
> alias Package[mysql-all] to ["mysql"] at
> /etc/puppet/modules/mysql/manifests/init.pp:21; resource
["Package",
> "mysql"] already declared at
> /etc/puppet/modules/redmine/manifests/dependencies.pp:80 at
> /etc/puppet/modules/mysql/manifests/init.pp:21 on node alan.dev.centos6
>
> I must set the name parameter because it''s the one that gets used
by the
> package manager, I''ve chosen different names for the resources but
it
> seems like puppet internally forces creating an alias using the package
> name.

The $name parameter is both the packaging system''s name for the
package and the Puppet name for the Package.  If you do not specify
the name parameter then it is taken from the resource title, but
setting different titles, as you have done, does not prevent a name
collision when you specify the same name for different packages.

> I''ve tried manually setting an alias, but nothing changes.
>
> puppetmaster: Debian squeeze, puppet 2.7.14
>
> client: Centos 6 32 bit, puppet 2.7.14.
>
> What should I do?

The best solution would be to create an RPM of the contents of the
Ruby gem, put it in a local repository, and install it via Yum.

Supposing that the gem is targeted at the system''s Ruby (instead of at
some additional, local, Ruby installation), installing via an RPM is
better administratively, as well.  It is never good to have multiple
agents managing overlapping spaces.


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.

On 05/04/2012 03:05 PM, jcbollinger wrote:
> The $name parameter is both the packaging system''s name for the
> package and the Puppet name for the Package.  If you do not specify
> the name parameter then it is taken from the resource title, but
> setting different titles, as you have done, does not prevent a name
> collision when you specify the same name for different packages.
Yes, I got that. But I''m not really sure whether this is a feature or a
misfeature, or maybe an implementation detail that came out this way.

I mean, resources aren''t scoped, so they all get pulled in a global
namespace AFAIK. Beyond the fact that this can create all kind of issues
with modules ( if two modules declare the same title, possibly for
different packages, you''ve got an unsolvable conflict there), this is
an
artificially induced conflict.

if ''name'' is the internal name used by the package manager,
and there''re
multiple different package managers around, I should be able to
differentiate resources. If I need to change the package manager''s name
- maybe for every release! - I do need to add a *lot* of overhead to my
configuration management system.

 The point of the name check is to prevent an *accidental* clash, but
this is not. This is not even a clash - it''s a different package.
> The best solution would be to create an RPM of the contents of the
> Ruby gem, put it in a local repository, and install it via Yum.
This is very time consuming and would require me to create a yum repo,
repack the gem every time I want to update it, instead of just switching
version. Puppet is meant to simplify deployments, not to make them more
complex, right?
> Supposing that the gem is targeted at the system''s Ruby (instead
of at
> some additional, local, Ruby installation), installing via an RPM is
> better administratively, as well.  It is never good to have multiple
> agents managing overlapping spaces.
I don''t agree on that - at least, I think you''re statement is
true only
if you''re mixing ruby packages installed via ''gem''
and ruby packages
installed via yum/rpm. But that''s not my case.

Installed gems are target at system ruby indeed, but while ruby and the
rubygem package itself is installed via system yum, gems are installed
via puppet only. There''s no overlap - no ruby gem gets installed via
rpm
at any time.

-- 
Latest blog post: Deploying WAR on Heroku http://t.co/M4krW2Mu
contact me at public@[mysurname].eu

-- 
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.