On Fri, Jun 06, 2014 at 07:30:56AM -0700, Richie wrote:
>
>
> I'm a little stuck with a puppet manifest due to the declarative nature of
> things and it's taking some time for the concept to fully sink in so could
> someone guide me in the right direction here (if this is the correct route
> of course).
>
> At the moment the setup is using vagrant, puppet and modules from puppet
> forge. The site manifest declares your typical LAMP stack which in it's
> most basic form works fine using the puppet modules and configuring
> accordingly.
>
> Currently I have a 'files/mysql/backup.sql.gz' structure inside Vagrantfile
> root dir and unfortunately the gz won't extract to /tmp/ using the
> /vagrant/files/mysql/back.sql.gz path as it's not recognised even though
> ssh'ing in reveals it - at a guess shares aren't active whilst provisioning?
>
> Following the successful extraction of the sql backup I'd like to import it
> then remove all traces of it so I guess the big question here would be is a
> routine task like this of scope for puppet and if not what approach should
> one taken given you can't declare the same resource twice (e.g. file {
> '/tmp/backup.sql':... ), one to ensure it exists and the other to ensure
> it's deleted.
>
> Thanks, any help appreciated.
Here is something that works for us:
define omysql::do($source=undef, $db, $content=undef) {
include omysql
include mysql::params
$script = "${omysql::sql_snippets}/${name}.sql"
file { $script:
mode => '0600',
source => $source,
content => $content,
}
exec {"mysql-import-${name}":
path => ['/bin', '/sbin', '/usr/bin'],
command => "mysql --defaults-file=/root/.my.cnf -A ${db} < ${script} &&
touch ${script}.semaphore",
creates => "${script}.semaphore",
require => [File[$script],Package[$mysql::params::server_package_name]],
timeout => '0',
}
}
Basically this creates a semaphore file to indicate if the file was
already imported. This was used on a simple project to do migrations and
initial data imports. Note that it requireds the puppetlabs module and
adds our sane defaults in omysql. A basic usage would be:
omysql::do{'my_cool_migration':
source => 'puppet:///modules/myproject/data.sql'
}
or
omysql::do{'my_cool_migration':
content => 'alter table ...'
}
This won't delete the data sql neither the 'alter table'. Not sure how
you would do that...
Note that for more complex requirements I would write a provider. Tell
us if you do so, I would be glad to use it(the define is just a little
hacky for this)
>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/707c54cc-6c07-424c-a12a-617516d4aee7%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20140611165539.GA7247%40nikolavp-desktop.
For more options, visit https://groups.google.com/d/optout.
