Hi Rich,
On Wed, Mar 20, 2013 at 5:54 AM, Rich Siegel <rismo...@gmail.com> wrote:
> My idea on reboots is different. I don't think we should have puppet do
> the reboot. If we go down this road, we need autologon, credentials,
> runonce, and a subsequent puppet agent run among other things.
Why do we need autologon and credentials?
Since puppet is typically running as an automatic windows service, it will
run immediately after machine reboot, and re-apply the catalog, picking up
where it left off (assuming the resources leading up the reboot are
correctly idempotent).
If you don't run puppet as a service, then you're probably going to need an
external orchestration process.
Not ideal if a puppet agent service is running during business time.
> This is orchestration and not where puppet should not be trying to succeed.
>
Sure, mcollective could be used to reboot en masse during a scheduled
maintenance windows, e.g. reboot all hosts where the reboot_pending fact is
true. But not everyone has or wants to setup mcollective, and reboots are a
common requirement on windows.
Originally I thought I needed a facter fact to determine if a reboot
> pending state existed, but the problem is that the facts are determined
> upfront. So if a resource triggers a "state" where a reboot is needed the
> fact is busted.
>
> I think we need a new embedded construct which can check the reboot state
> before processing every resource. It has to happen before it makes it to
> the provider since it should not be left to a provider author as it could
> apply to any resource. If this boolean goes true then every resource in
> that graph needs to be skipped.
>
So suppose we added a metaparameter to check if a reboot is pending, and
the metaparameter is set on a particular resource, e.g. package.
package { 'somepackage':
source => 'some.msi',
reboot_pending => check
}
Internally, that metaparameter could create an instance of a reboot_pending
resource, and setup a before/require relationship:
reboot_pending { '...':
before => Package['somepackage']
}
If the reboot_pending provider determines a reboot is necessary, then it
would cancel the transaction loop, causing all remaining resources to be
skipped. Puppet would remain in this state until the pending reboot is
cleared.
I don't think both approaches are mutually exclusive, though I think they
are modeling different things. The provider I created is about performing a
reboot as a result of another resource being applied (in cases where you
know a priori that a reboot will be necessary). Unfortunately, puppet
doesn't have a general mechanism for sending different types of events, so
all we know is the package was installed, but not whether it required a
reboot as a result.
The other approach, e.g. reboot_pending, is about modeling the reboot
pending state of the machine. This would be useful in cases where you don't
know ahead of time if a reboot will be necessary, or in cases that require
multiple reboots,
I think you could even combine them together in cases where you want puppet
to both detect that a reboot is pending and do the reboot:
package { 'somepackage':
source => 'some.msi',
reboot_pending => check
}
reboot_pending { 'somepackage':
before => Package['somepackage'],
}
reboot { 'now':
subscribe => Reboot_pending['somepackage'],
}
> A meta param can be added to say reboot => force which can force a
> resource to be processed _despite_ the boolean.
>
Isn't that the same as not specifying a reboot metaparameter? Or are you
saying only apply that resource, and skip the rest?
>
> I also need way to stateful trigger reboot flag like a lockfile so I can
> do a bios upgrade.
>
As a way of preventing puppet from applying changes? If so, you could add
an entry to the registry to make the system think a reboot is necessary.
>
> Actually _rebooting_ with puppet I am leery of. I welcome all input on
> 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 post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
Josh
--
Josh Cooper
Developer, Puppet Labs
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
