I didn''t run this (simplified) example so there might be errors, but
anyway -- say we have:
-----------------------------------------------------------
stage { aptstuff: }
Stage[aptstuff] -> Stage[main]
class proxy($url) {
file { "/etc/apt/apt.conf.d/02proxy":
content => "Acquire::http { Proxy \"$url\";
};",
}
}
class gnome3 {
# lots of packages and files
}
node vm15 {
class { proxy: url => "http://blah:9999", stage =>
aptstuff }
include gnome3
include otherstuff
}
-----------------------------------------------------------
Now, my expectation is that gnome3 will be in stage[main]
allowing the proxy to be set up before any packages are
installed. What I''m actually seeing is that the gnome
packages are installed, then the 02proxy file is written,
and finally other packages and files are installed/written.
So, what to do?
1. script the setup of the proxy during provisioning?
not ''declarative'', no good for brownfield deployment
2. Only use parametrized classes?
cuts into puppet forge''s usefulness
3. Something else?
And a separate question:
4. How do parameterized classes and inheritance fit together?
Is this or anything along these lines sensible?
class foo($greeting = "hi") {}
class baz($arg = "howdy!") inherits foo(greeting = $arg) {}
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Apr 27, 2:25 pm, vagn scott <vagnsc...@gmail.com> wrote:> I didn''t run this (simplified) example so there might be errors, but > anyway -- say we have: > > ----------------------------------------------------------- > > stage { aptstuff: } > > Stage[aptstuff] -> Stage[main] > > class proxy($url) { > file { "/etc/apt/apt.conf.d/02proxy": > content => "Acquire::http { Proxy \"$url\"; };", > } > > } > > class gnome3 { > # lots of packages and files > > } > > node vm15 { > > class { proxy: url => "http://blah:9999", stage => aptstuff } > include gnome3 > include otherstuff > > } > > ----------------------------------------------------------- > > Now, my expectation is that gnome3 will be in stage[main] > allowing the proxy to be set up before any packages are > installed. What I''m actually seeing is that the gnome > packages are installed, then the 02proxy file is written, > and finally other packages and files are installed/written.> So, what to do? > > 1. script the setup of the proxy during provisioning? > > not ''declarative'', no good for brownfield deploymentYou have to do some sort of provisioning to get Puppet working in the first place, so option (1) wouldn''t really be so bad.> 2. Only use parametrized classes? > > cuts into puppet forge''s usefulnessAbsolutely the wrong direction (says me). To the extent possible -- and that''s a very large extent -- use only *un*parameterized classes. I don''t see any particular reason to expect that using only parameterized classes would help here, anyway.> 3. Something else?First, consider why you (think you) need class Proxy to be parameterized. From where does the parameter value come? If it''s really fixed for all nodes, as in your example, then it would be better to make it an ordinary variable of class Proxy, or even to inline it. Perhaps you could switch to using source=> instead of content=>; then you could change the proxy host at need without modifying any manifests. If the proxy varies from node to node then consider moving the selection logic into class Proxy, or pushing it out by using extlookup() to retrieve it from an external file (where, again, you could change it without modifying manifest files). Either way, class proxy ends up not being parameterized. Then recognize that run stages are purely a convenience feature, providing nothing that you cannot get by using Puppet''s dependency system more directly. For instance, you could consider doing this at top level: Package { require => Class[''proxy''] } That sets a default value for the "require" parameter for all packages in scope, which, if that''s used at top level, are all packages in the manifest. Any package that does not specify its own require parameter will then be applied after class proxy. Adjust as needed for your situation.> And a separate question: > > 4. How do parameterized classes and inheritance fit together?As far as I know, they don''t fit together at all. Parameterized classes really should be thought of as a distinct thing from ordinary classes, offering similar features and bearing a confusingly similar name. If you have a need for class inheritance -- and the appropriate use cases are few -- then do not mix it with parameterized classes. Conveniently, that dovetails with my advice on your point #2. Best, John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/28/2011 09:54 AM, jcbollinger wrote:
>
> You have to do some sort of provisioning to get Puppet working in the
> first place, so option (1) wouldn''t really be so bad.
>
There is no question that it could be done in provisioning.
My question is really: How do stages work?
Can I use stages to, as in this example, set up
a proxy that should be in place before
any other classes are expressed?
>
> Absolutely the wrong direction (says me). To the extent possible --
> and that''s a very large extent -- use only *un*parameterized
classes.
> I don''t see any particular reason to expect that using only
> parameterized classes would help here, anyway.
>
Oh good. But, to rephrase the question, can I control the
stage an unparameterized class gets expressed in? Or, is
it guaranteed that unparameterized classes are expressed in
stage[main]? Because if not, it is useless to have
parameterized classes that want to run before stage[main].
>
> First, consider why you (think you) need class Proxy to be
> parameterized.
Because, according to the docs I''ve seen, only parameterized
classes run in stages other than stage[main]. Please clarify
if I''m mistaken.
> From where does the parameter value come? If it''s
> really fixed for all nodes, as in your example, then it would be
> better to make it an ordinary variable of class Proxy, or even to
> inline it. Perhaps you could switch to using source=> instead of
> content=>; then you could change the proxy host at need without
> modifying any manifests.
Don''t get sidetracked by the details of the example.
My question is about expressing sequence dependencies in puppet.
The proxy is a real-life example of something that should be done first,
never mind that there are other ways to do it.
> Then recognize that run stages are purely a convenience feature,
> providing nothing that you cannot get by using Puppet''s
dependency
> system more directly. For instance, you could consider doing this at
> top level:
>
> Package { require => Class[''proxy''] }
But I really don''t want to require it.
I want to express that IF a node has Class[''proxy''],
then proxy needs to go first.
> Any package that does not specify its own require parameter
> will then be applied after class proxy.
This breaks modularity, orthogonality and encapsulation.
If I have a class with no require in Package{},
and then decide to add it, I unwittingly change it''s global sequence
relationships as well. It would work if the require
relationships accumulated, rather than got redefined, but that
has its own problems.
>> 4. How do parameterized classes and inheritance fit together?
>
> As far as I know, they don''t fit together at all. Parameterized
> classes really should be thought of as a distinct thing from ordinary
> classes, offering similar features and bearing a confusingly similar
> name. If you have a need for class inheritance -- and the appropriate
> use cases are few -- then do not mix it with parameterized classes.
Cool. I can definitely live with that.
But, I am left wondering if there is any utility to the stage[]
concept at all.
Puppets dependencies seem to be:
provisioning
network config
backup/restore/disaster recovery
kernel/filesystem config
puppet config
Puppet can affect these things in only a limited way. And, generally,
they all
have to be there before puppet is useful.
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Apr 28, 2:07 pm, vagn scott <vagnsc...@gmail.com> wrote:> On 04/28/2011 09:54 AM, jcbollinger wrote: > > > > You have to do some sort of provisioning to get Puppet working in the > > first place, so option (1) wouldn''t really be so bad. > > > > There is no question that it could be done in provisioning. > > My question is really: How do stages work? > Can I use stages to, as in this example, set up > a proxy that should be in place before > any other classes are expressed?Run stages leverage Puppet''s existing dependency system, to which the "require" and "before" resource metaparameters and other features are also hooked. A run stage essentially creates a node in the dependency graph such that all classes assigned to that stage have a "before" relationship with that stage and a "require" relationship with all previous stages. You can achieve exactly the same effect without run stages, but it can be messy.> > Absolutely the wrong direction (says me). To the extent possible -- > > and that''s a very large extent -- use only *un*parameterized classes. > > I don''t see any particular reason to expect that using only > > parameterized classes would help here, anyway. > > > > Oh good. But, to rephrase the question, can I control the > stage an unparameterized class gets expressed in? Or, is > it guaranteed that unparameterized classes are expressed in > stage[main]? Because if not, it is useless to have > parameterized classes that want to run before stage[main].You can use the class { "foo": ... } syntax with unparameterized classes to assign them to stages (or simply as an alternative to "include"), but only once each. I do not recommend also "include" ing the same classes elsewhere in the manifest, which otherwise you could do with an unparameterized class.> > First, consider why you (think you) need class Proxy to be > > parameterized. > > Because, according to the docs I''ve seen, only parameterized > classes run in stages other than stage[main]. Please clarify > if I''m mistaken.You are mistaken. You must use the class {"foo": } syntax to assign a class to a run stage, but that class does not need to be parameterized.> > From where does the parameter value come? If it''s > > really fixed for all nodes, as in your example, then it would be > > better to make it an ordinary variable of class Proxy, or even to > > inline it. Perhaps you could switch to using source=> instead of > > content=>; then you could change the proxy host at need without > > modifying any manifests. > > Don''t get sidetracked by the details of the example. > My question is about expressing sequence dependencies in puppet. > The proxy is a real-life example of something that should be done first, > never mind that there are other ways to do it.My point is not so much to quibble the details, but to assert that parameterized classes in general are not everything that they are cracked up to be. I like run stages better than parameterized classes, to the extent that they are separable, but I don''t think those are the first tool anyone should reach for to deal with resource ordering issues. That''s why I am suggesting alternatives.> > Then recognize that run stages are purely a convenience feature, > > providing nothing that you cannot get by using Puppet''s dependency > > system more directly. For instance, you could consider doing this at > > top level: > > > > Package { require => Class[''proxy''] } > > But I really don''t want to require it. > I want to express that IF a node has Class[''proxy''], > then proxy needs to go first.That strikes me as a possible conceptualization problem, and, separately, a possible design problem: On the conceptual level, what does it or *should* it mean that a node has Class[''proxy'']? To you it seems to mean that the node positively uses an HTTP proxy, at least for Apt. But it could instead mean that the node''s proxy configuration is managed, which might include ensuring that it doesn''t use a proxy. And that''s where the design problem comes in: what do you do if a node configured with a proxy ever needs to be reconfigured for direct connection? Simply excluding Class[''proxy''] from that node''s manifest doesn''t do the job: you must actively manage the config file absent. You could do that by including a different class instead, but it''s smoother to give Class[''proxy''] enough brains to know whether to configure the node with a proxy or without. If you do that then you can include it on every node, and you probably would want to do so.> > Any package that does not specify its own require parameter > > will then be applied after class proxy. > > This breaks modularity, orthogonality and encapsulation.Any resource that affects the application of resources in different scopes does this -- for an oh-so-random example, a resource that affects how the system''s package provider operates. Problems without those characteristics are poor candidates for run stages in the first place.> If I have a class with no require in Package{}, > and then decide to add it, I unwittingly change it''s global sequence > relationships as well. It would work if the require > relationships accumulated, rather than got redefined, but that > has its own problems.That is all true. Any approach has its advantages and disadvantages, and my message is not that the default parameter approach is superior. I simply want to challenge you to consider whether run stages are the best solution for your particular problem, and it''s entirely possible that they are. It is also possible, however, that they are not.> >> 4. How do parameterized classes and inheritance fit together? > > > > As far as I know, they don''t fit together at all. Parameterized > > classes really should be thought of as a distinct thing from ordinary > > classes, offering similar features and bearing a confusingly similar > > name. If you have a need for class inheritance -- and the appropriate > > use cases are few -- then do not mix it with parameterized classes. > > Cool. I can definitely live with that. > > But, I am left wondering if there is any utility to the stage[] > concept at all.I think there is. In particular, I think it''s more broadly applicable than you supposed. On the other hand, it''s by no means a panacea for dependency problems, and sometimes it even makes them worse by introducing formal dependencies that aren''t actually needed.> Puppets dependencies seem to be: > provisioning > network config > backup/restore/disaster recovery > kernel/filesystem config > puppet config > > Puppet can affect these things in only a limited way. And, generally, > they all > have to be there before puppet is useful.Puppet does have its dependencies and limits, just like any other management application. As far as I am aware, those that operate in the context of a running system, like Puppet does, all have dependencies and limits more or less along those lines. Those that operate by different means (e.g. some forms of VM-based systems) have different limits and dependencies. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/29/2011 10:53 AM, jcbollinger wrote:
>
> On the conceptual level, what does it or *should* it mean that a node
> has Class[''proxy'']? To you it seems to mean that the
node positively
> uses an HTTP proxy, at least for Apt. But it could instead mean that
> the node''s proxy configuration is managed, which might include
> ensuring that it doesn''t use a proxy.
>
This is an excellent starting point. Let''s just focus
on this assertion: "The proxy configuration is managed".
And let us add that, if the proxy config is wrong, packages may
not get installed on a node (for one puppet run anyway).
The most likely downside is that a puppet run will partially fail
because the proxy gets configured somewhere in the middle of the run.
But, on the next run, things work ok, so not a showstopper.
And, let''s forget for the moment that there or non-puppet solutions.
And, I will leave out any example implementation, so there is nothing to
pick at there.
But any solution in puppet should, as you point out, either establish
or remove a proxy, depending on something. Maybe a choice of
apt::proxy or apt::noproxy, or maybe some parameter or variable value.
But by its nature the proxy config is something we would like to have
happen first.
Can this be expressed in puppet as a drop in? Can I design a module
that manages the proxy, such that when I add that module to an existing
design, I don''t have to visit every module and add a require in order
to control the order of things?
It appears that I cannot.
What changes to puppet would make it possible?
1. all classes are in stage[main] by default.
Then the API for the proposed proxy module could require that
- stage[proxy] be defined
- stage[proxy] is put in sequence before any stages
that allow packages to be installed
and the implementation could have a helper class that does the
actual configuration, with only the helper class declared as
being in stage[proxy]
Something similar could be done to solve the reboot problem.
The API for the reboot module could require that
- stage[reboot] be defined
- stage[reboot] is last in sequence
- modules would post a need to reboot with
notify => Class[ "reboot" ]
John, BTW thanks for your answers. They are very helpful.
--
vagn
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
R.I.Pienaar
2011-Apr-29 16:29 UTC
Re: [Puppet Users] Re: run stages and mixed class styles
----- Original Message -----> On 04/29/2011 10:53 AM, jcbollinger wrote: > > > > On the conceptual level, what does it or *should* it mean that a > > node > > has Class[''proxy'']? To you it seems to mean that the node > > positively > > uses an HTTP proxy, at least for Apt. But it could instead mean > > that > > the node''s proxy configuration is managed, which might include > > ensuring that it doesn''t use a proxy. > > > > This is an excellent starting point. Let''s just focus > on this assertion: "The proxy configuration is managed". > > And let us add that, if the proxy config is wrong, packages may > not get installed on a node (for one puppet run anyway). > > The most likely downside is that a puppet run will partially fail > because the proxy gets configured somewhere in the middle of the run. > But, on the next run, things work ok, so not a showstopper. > > And, let''s forget for the moment that there or non-puppet solutions. > > And, I will leave out any example implementation, so there is nothing > to > pick at there. > > But any solution in puppet should, as you point out, either establish > or remove a proxy, depending on something. Maybe a choice of > apt::proxy or apt::noproxy, or maybe some parameter or variable > value. > > But by its nature the proxy config is something we would like to have > happen first. > > Can this be expressed in puppet as a drop in? Can I design a module > that manages the proxy, such that when I add that module to an > existing > design, I don''t have to visit every module and add a require in order > to control the order of things? > > It appears that I cannot.Sounds like you want resource chaining[1], you can resource chaining to affect the order of lots of other resources/classes. So: class aptproxy { # set up the proxy Class["aptproxy"] -> Package <| provider == apt |> } now if you include the proxy class it will adjust the relationships on packages using apt else those packages wont have the relationship at all. careful though this has an unfortunate side effect that it will also realize all virtual packages with the provider apt onto a node. point is you *can* tweak dependencies as a result of including a class. [1] http://docs.puppetlabs.com/guides/language_guide.html#chaining-resources -- R.I.Pienaar -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/29/2011 12:29 PM, R.I.Pienaar wrote: > > Sounds like you want resource chaining[1] > > careful though this has an unfortunate side effect that it > will also realize all virtual packages with the provider apt > onto a node. > > point is you *can* tweak dependencies as a result of including > a class. Not exactly what I''m looking for, then. > [1] http://docs.puppetlabs.com/guides/language_guide.html#chaining-resources Anyway, thanks for the pointer. -- vagn If we had some ham, we could have eggs and ham, if we only had some eggs. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I took another pass at this and it seems to work the way I expected it to. I''m not sure why it didn''t work before, and I don''t have time right now to look into it. Anyway, thanks to those who replied. If I find anything interesting I will post it. -- thanks, vagn On 04/29/2011 10:53 AM, jcbollinger wrote:> > On Apr 28, 2:07 pm, vagn scott<vagnsc...@gmail.com> wrote: > >> On 04/28/2011 09:54 AM, jcbollinger wrote: >> > >> > You have to do some sort of provisioning to get Puppet working in the >> > first place, so option (1) wouldn''t really be so bad. >> > >> >> There is no question that it could be done in provisioning. >> >> My question is really: How do stages work? >> Can I use stages to, as in this example, set up >> a proxy that should be in place before >> any other classes are expressed? >> > Run stages leverage Puppet''s existing dependency system, to which the > "require" and "before" resource metaparameters and other features are > also hooked. A run stage essentially creates a node in the dependency > graph such that all classes assigned to that stage have a "before" > relationship with that stage and a "require" relationship with all > previous stages. > > You can achieve exactly the same effect without run stages, but it can > be messy. > > >> > Absolutely the wrong direction (says me). To the extent possible -- >> > and that''s a very large extent -- use only *un*parameterized classes. >> > I don''t see any particular reason to expect that using only >> > parameterized classes would help here, anyway. >> > >> >> Oh good. But, to rephrase the question, can I control the >> stage an unparameterized class gets expressed in? Or, is >> it guaranteed that unparameterized classes are expressed in >> stage[main]? Because if not, it is useless to have >> parameterized classes that want to run before stage[main]. >> > You can use the class { "foo": ... } syntax with unparameterized > classes to assign them to stages (or simply as an alternative to > "include"), but only once each. I do not recommend also "include" ing > the same classes elsewhere in the manifest, which otherwise you could > do with an unparameterized class. > > >> > First, consider why you (think you) need class Proxy to be >> > parameterized. >> >> Because, according to the docs I''ve seen, only parameterized >> classes run in stages other than stage[main]. Please clarify >> if I''m mistaken. >> > You are mistaken. You must use the class {"foo": } syntax to assign a > class to a run stage, but that class does not need to be > parameterized. > > >> > From where does the parameter value come? If it''s >> > really fixed for all nodes, as in your example, then it would be >> > better to make it an ordinary variable of class Proxy, or even to >> > inline it. Perhaps you could switch to using source=> instead of >> > content=>; then you could change the proxy host at need without >> > modifying any manifests. >> >> Don''t get sidetracked by the details of the example. >> My question is about expressing sequence dependencies in puppet. >> The proxy is a real-life example of something that should be done first, >> never mind that there are other ways to do it. >> > > My point is not so much to quibble the details, but to assert that > parameterized classes in general are not everything that they are > cracked up to be. I like run stages better than parameterized > classes, to the extent that they are separable, but I don''t think > those are the first tool anyone should reach for to deal with resource > ordering issues. That''s why I am suggesting alternatives. > > > >> > Then recognize that run stages are purely a convenience feature, >> > providing nothing that you cannot get by using Puppet''s dependency >> > system more directly. For instance, you could consider doing this at >> > top level: >> > >> > Package { require => Class[''proxy''] } >> >> But I really don''t want to require it. >> I want to express that IF a node has Class[''proxy''], >> then proxy needs to go first. >> > > That strikes me as a possible conceptualization problem, and, > separately, a possible design problem: > > On the conceptual level, what does it or *should* it mean that a node > has Class[''proxy'']? To you it seems to mean that the node positively > uses an HTTP proxy, at least for Apt. But it could instead mean that > the node''s proxy configuration is managed, which might include > ensuring that it doesn''t use a proxy. > > And that''s where the design problem comes in: what do you do if a node > configured with a proxy ever needs to be reconfigured for direct > connection? Simply excluding Class[''proxy''] from that node''s manifest > doesn''t do the job: you must actively manage the config file absent. > You could do that by including a different class instead, but it''s > smoother to give Class[''proxy''] enough brains to know whether to > configure the node with a proxy or without. If you do that then you > can include it on every node, and you probably would want to do so. > > > >> > Any package that does not specify its own require parameter >> > will then be applied after class proxy. >> >> This breaks modularity, orthogonality and encapsulation. >> > > Any resource that affects the application of resources in different > scopes does this -- for an oh-so-random example, a resource that > affects how the system''s package provider operates. Problems without > those characteristics are poor candidates for run stages in the first > place. > > > >> If I have a class with no require in Package{}, >> and then decide to add it, I unwittingly change it''s global sequence >> relationships as well. It would work if the require >> relationships accumulated, rather than got redefined, but that >> has its own problems. >> > > That is all true. Any approach has its advantages and disadvantages, > and my message is not that the default parameter approach is > superior. I simply want to challenge you to consider whether run > stages are the best solution for your particular problem, and it''s > entirely possible that they are. It is also possible, however, that > they are not. > > > >> >> 4. How do parameterized classes and inheritance fit together? >> > >> > As far as I know, they don''t fit together at all. Parameterized >> > classes really should be thought of as a distinct thing from ordinary >> > classes, offering similar features and bearing a confusingly similar >> > name. If you have a need for class inheritance -- and the appropriate >> > use cases are few -- then do not mix it with parameterized classes. >> >> Cool. I can definitely live with that. >> >> But, I am left wondering if there is any utility to the stage[] >> concept at all. >> > > I think there is. In particular, I think it''s more broadly applicable > than you supposed. On the other hand, it''s by no means a panacea for > dependency problems, and sometimes it even makes them worse by > introducing formal dependencies that aren''t actually needed. > > > >> Puppets dependencies seem to be: >> provisioning >> network config >> backup/restore/disaster recovery >> kernel/filesystem config >> puppet config >> >> Puppet can affect these things in only a limited way. And, generally, >> they all >> have to be there before puppet is useful. >> > > Puppet does have its dependencies and limits, just like any other > management application. As far as I am aware, those that operate in > the context of a running system, like Puppet does, all have > dependencies and limits more or less along those lines. Those that > operate by different means (e.g. some forms of VM-based systems) have > different limits and dependencies. > > > John > >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 29, 11:29 am, "R.I.Pienaar" <r...@devco.net> wrote:> Sounds like you want resource chaining[1], you can resource chaining to affect > the order of lots of other resources/classes. > > So: > > class aptproxy { > # set up the proxy > > Class["aptproxy"] -> Package <| provider == apt |> > > } > > now if you include the proxy class it will adjust the > relationships on packages using apt else those packages > wont have the relationship at all.That''s a nice one. I had forgotten that resource chaining could be applied that way.> careful though this has an unfortunate side effect that it > will also realize all virtual packages with the provider apt > onto a node.Yes, that''s an important drawback if you''re concerned about the most general case. I tend not to use virtual packages, as (unparameterized) classes provide everything I need for which I might otherwise use virtual packages, but that''s just me. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.