On Friday, June 6, 2014 9:30:56 AM UTC-5, 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).
>
I like to describe Puppet DSL's declarative nature by focusing on how you
use it, rather than on how you can classify it. Specifically, writing
Puppet manifests is an exercise in *modeling* the desired target state of
your machines, as opposed to some other CM systems' focus on how to modify
the target system. The Puppet approach has great advantages, especially
for managing heterogeneous infrastructure, but you do have to make a mental
adjustment to make the best use of it.
> 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?
>
I'm not a big Vagrant guy, so I don't think I fully understand the
question. I would expect, however, that which filesystems are mounted
during vagrant-directed provisioning would be under vagrant's control.
> 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.
>
Remember that with Puppet you are modeling the *target* state. If
/tmp/backup.sql is not part of the desired final state, then it should not
appear (as a resource in its own right) in the model you construct. That
doesn't mean Puppet cannot handle this situation -- there are a variety of
approaches to problems like this. Which solution would be best depends on
your specific circumstances, however. A rather important consideration
there is whether the target machines will continue to be managed by Puppet
after provisioning, as opposed to Puppet being used exclusively as part of
the one-time provisioning process for each machine.
Either way, though, I have a hard time believing that vagrant cannot be
persuaded to drop the uncompressed file into the location of your choice on
the target machine during provisioning. If you can make that happen then
taking it the rest of the way via Puppet will be easier than making Puppet
do the whole thing.
John
--
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/1813a54d-6d2b-4574-a793-ce7cdacbd7cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
