Puppet already has stage[ Main ] which is the only
stage it needs to define. All other stages
can be defined relative to main and each other, and should
be a matter of convention. So I think it would be more
fruitful to talk about the purpose of stages, along with
their proposed names.
For example, I have a class that sets up the apt proxy.
It defines two stages: preupdate followed by update.
Their purpose is to set up the network environment
needed for downloading packages, so the implication is
that any class that installs packages must be
expressed later in the run.
I would diagram it like this:
preupdate -> update -> ... -> main
|
+---- no apt proxy before this point
--
vagn
On 06/10/2011 04:20 AM, Chris Phillips wrote:
On 10 June 2011 09:06, Brice Figureau <brice-pup...@daysofwonder.com
<mailto:brice-pup...@daysofwonder.com>> wrote:
On Thu, 2011-06-09 at 18:50 -0700, Jacob Helwig wrote:
> On Thu, 09 Jun 2011 18:42:54 -0700, Nigel Kersten wrote:
> >
> > https://projects.puppetlabs.com/issues/7697
> >
> > One problem people producing modules that make use of stages
are hitting is
> > that it's difficult to create something reusable that
integrates seamlessly
> > into existing setups.
> >
> > This feature request is to add several more implicit stages to
Puppet so we
> > have:
> >
> > bootstrap
> > pre
> > main
> > post
> >
> > existing by default, making it easier for authors to specify
stages in their
> > modules.
> >
> > Thoughts?
> >
>
> The answer to question "Which comes first, 'bootstrap' or 'pre'?"
seems
> awfully ambiguous from just the names.
>
> What's the reason for separating it out?
One of the reason would be for the bootstrap phase to happen in its own
run instead of being part of the standard run. That would allow to
pre-install stuff that plugins could use (like for instance mysqladmin
for the mysql types). Then the 3 other stages would happen in the same
run.
It would also be great to have this stage being optional in subsequent
runs, allowing you to use the bootstrap stage during provisioning (ie
just after a pre-seed or kickstart), but never again. This would help
bootstrap from bare-metal.
Whilst it initially sounds useful, is that distinction not somewhat
arbitrary? The standard logic conventions can deal with that already and
you'd then also need to define what constitutes the provisioning run. I
suppose a command line parameter on the call in the kickstart is easy
enough, but then surely that model would need to be generic across all
stages and not only targeted at one stage?
--
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.
--
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.
