Puppet users - May 2009 - Problematic provider dependencies

Good day,

Does puppet have a way of setting up provider dependencies before
setting up the provider itself?

Here''s the scenario I''m trying to get working: I have some
machines
that need to be database servers. I also have a mysql type/provider
that manages users and databases.

However, the provider only works if mysql is already installed, since
it requires ''/usr/bin/mysql'' to be present and fails the
suitability
test if the binary is missing. Thus, I cannot install mysql and then
configure it -- I must install it by hand or using a class that does
the installation without any configuration and then change classes
once it is installed.

I have tried using "optional_commands" instead of "commands"
in the
provider code. This allows the provider to be used, but it fails when
it tries to test or create resources because the command binaries are
apparently resolved at startup.

I had a hack in place that would pretend to configure mysql using fake
commands, which lets me set up the database as a two-step operation.
However, this requires additional code to test for the existence of
mysql around every further operation that requires the database to be
present.

The best solution I can see at the moment is to rewrite the provider
to do everything manually instead of using the built-in command
infrastructure. Are there any other options?

Thanks,
--J

--~--~---------~--~----~------------~-------~--~----~
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 Wed, May 13, 2009 at 8:19 AM, jerith <firxen@gmail.com>
wrote:
>
> Good day,
>
> Does puppet have a way of setting up provider dependencies before
> setting up the provider itself?
>
> Here''s the scenario I''m trying to get working: I have
some machines
> that need to be database servers. I also have a mysql type/provider
> that manages users and databases.
>
> However, the provider only works if mysql is already installed, since
> it requires ''/usr/bin/mysql'' to be present and fails the
suitability
> test if the binary is missing. Thus, I cannot install mysql and then
> configure it -- I must install it by hand or using a class that does
> the installation without any configuration and then change classes
> once it is installed.
>
> I have tried using "optional_commands" instead of
"commands" in the
> provider code. This allows the provider to be used, but it fails when
> it tries to test or create resources because the command binaries are
> apparently resolved at startup.
>
> I had a hack in place that would pretend to configure mysql using fake
> commands, which lets me set up the database as a two-step operation.
> However, this requires additional code to test for the existence of
> mysql around every further operation that requires the database to be
> present.
>
> The best solution I can see at the moment is to rewrite the provider
> to do everything manually instead of using the built-in command
> infrastructure. Are there any other options?
>
> Thanks,
> --J
>
You should be able to do this using the the require and before
metatypes. Have the package{"mysql": before =>
Exec["mysql-config]}.
Some thing liek that should get teh ordering correct for you.

Evan

--~--~---------~--~----~------------~-------~--~----~
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 Wed, May 13, 2009 at 20:59, Evan Hisey <ehisey@gmail.com>
wrote:
> You should be able to do this using the the require and before
> metatypes. Have the package{"mysql": before =>
Exec["mysql-config]}.
> Some thing liek that should get teh ordering correct for you.
The problem is that the provider suitability resolution happens before
any of the ordering. Consider the following simplified class:

class mysql {
    package { "mysql-client": ensure => installed }
    package { "mysql-server": ensure => installed }
    mysql_user { "user@localhost":
        password_hash => "hashed password",
        require => [Package["mysql-server"],
Package["mysql-client"]],
    }
}

One would expect the two packages would be installed and then the new
db user to be created. However, the mysql_user provider needs
/usr/bin/mysql to be present. Since it isn''t (because mysql
isn''t
installed yet), no suitable providers are found and the run fails
immediately.

If I rewrite the provider to call the various commands directly
instead of using the commands() method, the provider is determined to
be suitable. However, careful ordering must be used to ensure that
mysql has been installed at any point the provider is called. One
unfortunate consequence of this is that the mysql types cannot be
required by anything else, because the require check may happen before
mysql has been installed and then a bunch of stuff fails.

I currently have a fragile collection of require and before specifiers
scattered all over the place and files that are created for the sole
purpose of being synchronisation points, like so:

class mysql {
    package { "mysql-client": ensure => installed }
    package { "mysql-server": ensure => installed }
    mysql_user { "user@localhost":
        password_hash => "hashed password",
        require => [Package["mysql-server"],
Package["mysql-client"]],
        before => File["/var/cruft/mysql_post_inst"],
    }
    file { "/var/cruft/mysql_post_inst": content => "" }
}

class otherstuff {
    package { "myapp": ensure => installed }
    mysql_user { "appuser@localhost":
        password_hash => "hashed password",
        require => [Package["mysql-server"],
Package["mysql-client"]],
        before => File["/var/cruft/mysql_post_inst"],
    }
    mysql_database { "appdb":
        require => [Package["mysql-server"],
Package["mysql-client"]],
        before => File["/var/cruft/mysql_post_inst"],
    }
    exec { "/usr/local/share/myapp/dbsetup":
        subscribe => Package["myapp"],
        refreshonly => true,
        require => File["/var/cruft/mysql_post_inst"],
    }
}

Of course, in my case I have several of these synchronisation points
because there are several steps that each require a previous set of
operations to be completed before they are valid.

Is this really the best way to handle such dependencies?

--J

--~--~---------~--~----~------------~-------~--~----~
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 5/13/2009 4:10 PM, Jeremy Thurgood wrote:
> The problem is that the provider suitability resolution happens before
> any of the ordering. Consider the following simplified class:
> 
> class mysql {
>     package { "mysql-client": ensure => installed }
>     package { "mysql-server": ensure => installed }
>     mysql_user { "user@localhost":
>         password_hash => "hashed password",
>         require => [Package["mysql-server"],
Package["mysql-client"]],
>     }
> }
> 
> One would expect the two packages would be installed and then the new
> db user to be created. However, the mysql_user provider needs
> /usr/bin/mysql to be present. Since it isn''t (because mysql
isn''t
> installed yet), no suitable providers are found and the run fails
> immediately.
I may be naive here, since I''ve never written my own types, but
I''m
wondering if a puppet definition for mysql_user would be better than 
writing a native puppet type. Something like:

   mysql_user { "user@localhost": password_hash => "hashed
password" }

with:

   define mysql_user (
     $password_hash = "someknownhash"
   ) {
     exec { "create_$name":
       command => "mysql -e ''CREATE USER $name IDENTIFIED BY
PASSWORD
$password_hash''",
       require => [Package["mysql-server"],
Package["mysql-client"]],
     }
   }

The types I see on the documentation pages all appear to be written in 
straight Ruby, and don''t rely on external programs to run.

-- 
Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

--~--~---------~--~----~------------~-------~--~----~
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 Thu, May 14, 2009 at 00:35, Mike Renfro <renfro@tntech.edu>
wrote:
> I may be naive here, since I''ve never written my own types, but
I''m
> wondering if a puppet definition for mysql_user would be better than
> writing a native puppet type. Something like:
>
>   mysql_user { "user@localhost": password_hash => "hashed
password" }
>
> with:
>
>   define mysql_user (
>     $password_hash = "someknownhash"
>   ) {
>     exec { "create_$name":
>       command => "mysql -e ''CREATE USER $name IDENTIFIED
BY PASSWORD
> $password_hash''",
>       require => [Package["mysql-server"],
Package["mysql-client"]],
>     }
>   }
This was the first thing I looked at, actually. Unfortunately, dealing
with permissions and grants is complex enough that I couldn''t find a
way to do it in pure puppet.
> The types I see on the documentation pages all appear to be written in
> straight Ruby, and don''t rely on external programs to run.
Using external programs is fine, even easy, as long as they are
already present when puppet loads the provider. If you sneak around
behind its back, you have to manage everything carefully yourself,
which is what I''m struggling with.

--J

--~--~---------~--~----~------------~-------~--~----~
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 version of Puppet are you running?

The goal is to be able to set up prerequisites for suitability during a run
and have it work.

I thought this was working in new versions.

I have a git provider just waiting for a bit of spare time the would require
this type of logic on most systems and if this isn''t working,
I''d consider
it an open issue.

Cheers,
Andrew

--~--~---------~--~----~------------~-------~--~----~
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, May 19, 2009 at 07:58, Andrew Shafer <andrew@reductivelabs.com>
wrote:
>
> What version of Puppet are you running?
0.24.4 -- it''s the one that''s in the Ubuntu Hardy repository.
I could
upgrade, but I would prefer to avoid the effort of setting up
appropriate repositories if I can.
> The goal is to be able to set up prerequisites for suitability during a run
> and have it work.
I think one possible issue here is that commands() adds dependencies
on specific files and puppet doesn''t know that a package I''m
about to
install will provide those files. I''ll try adding a package or service
prerequisite and see if that works.
> I thought this was working in new versions.
>
> I have a git provider just waiting for a bit of spare time the would
require
> this type of logic on most systems and if this isn''t working,
I''d consider
> it an open issue.
I think I''ve worked around most of the issues, but I''ve
learned a huge
amount about how types and providers work while I''ve been doing it.
It''s entirely possible that most of my problems were due to
misunderstandings and that when I''ve had a few moments to clean things
up a bit.

Thanks,
--J

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