Hi Amos,
One of the least hacky ways I've found around the chicken and egg
scenario is to use Custom facts to determine what state Agent is in and
then use or don't use your providers accordingly. For example I have a
fact for determining if ruby-libvirt is installed and Puppet has set up
the necessary networking so I know I can use the 'virt' custom provider
to create VMs. Unfortunately it requires multiple passes, but removes
the need for manual intervention and intermediate errors from the logs.
-Luke
On 23/03/12 06:35, Amos Shapira wrote:
Thanks for the pointer, Gary.
It seems to address the issue of missing providers, even better than
my suggestion.
However, I'm not sure if/how it addresses other situations, e.g.:
1. Provider exists but has to be updated.
2. Puppet version update.
3. Configuration files - missing or have to be updated.
4. Other types of configurations which have to take place, e.g. add a
network link (e.g. VPN, proxy), or make any other arbitrary change
which can affect the rest of the puppet run (or future puppet runs).
What I'm thinking about is a generic way to say "OK, now I'm finished
doing all sorts of tweaks to the system, please start puppet and take
these tweaks into consideration".
Is that possible?
Cheers,
--Amos
On Wednesday, March 21, 2012 1:51:48 PM UTC+11, Gary Larizza wrote:
On Wed, Mar 21, 2012 at 1:11 PM, Amos Shapira
<amos.shap...@gmail.com <mailto:amos.shap...@gmail.com>> wrote:
Hello,
I encounter issues regarding puppet "self update" that I'm
sure are
not uncommon:
1. When puppet version updates it doesn't restart to run the
rest of
the manifest with the new version.
2. When a new provider is installed (or extra configuration is
done to
enable an existing provider), puppet still won't make it
available.
example for (1): Our vagrant (http://vagrantup.com/) dev base
boxes
still come with Puppet 2.6.3 while the manifest depends on
Puppet 2.7
features. I can manually upgrade puppet manually (and that's
what I do
on dev), but when the time to deploy to production comes it
practically means that I have to manually upgrade Puppet to
2.7 on all
hosts before I push the change.
example for (2): We use daemontools
(http://cr.yp.to/daemontools. html
<http://cr.yp.to/daemontools.html>)
to monitor some of our servers. Puppet comes with a "daemontools"
Service type provider but since the daemontools package isn't
installed yet the provider is made unavailable for the rest of the
run. A second puppet run, assuming it managed to install
daemontools
in the first one before it failed on other things, succeeds in
picking
up the daemontools as a provider.
another example for (2): I use opsview
(https://github.com/dpeters/
puppet-opsview <https://github.com/dpeters/puppet-opsview>) to
monitor hosts. When the type is loaded by puppet it
looks for a file called /etc/puppet/opsview.conf to find
URL/username/
password of the opsview REST server. This file doesn't exist
(or can
be out of date) in the first run causing the Type to fail.
Amos, have you seen this feature --> http://projects.
puppetlabs.com/issues/6907
<http://projects.puppetlabs.com/issues/6907>
My suggestion -
Define a new "preload" stage - resources which can affect
puppet's own
execution (e.g. types, config files, puppet version updates)
can be
placed in that stage and eventually a specific function call (or a
special built-in trigger inside the Puppet code?) will cause
Puppet to
drop everything at the end of this stage and start from fresh.
The mechanism has to be careful to limit potential inifinite
loops -
e.g. if nothing was changed during the stage then don't
re-run, or if
the stage keeps changing things and puppet re-starts more than
a set
limit then fail.
What do you think about this? Is there another
solution/work-around/
standard-best-practice I'm not aware of?
Thanks.
--
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
<mailto:puppet-users@googlegroups.com>.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@ googlegroups.com
<mailto:puppet-users%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/ group/puppet-users?hl=en
<http://groups.google.com/group/puppet-users?hl=en>.
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/XUeixQ5zq7sJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way.
If you are not a named recipient please notify the sender immediately and
delete any copies of this message. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any view or
opinions presented are solely those of the author and do not necessarily
represent those of the company.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
