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 puppet-users+unsubscr...@googlegroups.com.
> 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 puppet-users+unsubscr...@googlegroups.com.
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.
