In this situation, the problem you need to address isn't Puppet, it's
your infrastructure. The infrastructure you describe is going to be
nuts to manage no matter what set of tools you are trying to use. It
doesn't make the tools deficient.
Basically, if you build your house on a swamp, don't complain that
there are no building materiels that you can use to keep your house
from sinking.
--Paul
On Thu, May 20, 2010 at 2:35 PM, Douglas Garstang
<doug.garst...@gmail.com> wrote:
> On Thu, May 20, 2010 at 2:18 PM, Steven VanDevender <ste...@uoregon.edu>
> wrote:
>> Douglas Garstang writes:
>> > On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop <paul.lath...@gmail.com>
>> wrote:
>> > > You are getting a bunch of misguided answers to this. I'm also
>> > > perplexed by your assertion that external nodes requires you to write
>> > > custom scripts to parse node manifests.
>> > >
>> > > No, you cannot put resources directly into nodes when you are using
>> > > external nodes. In practice, this hasn't mattered; you wrap your
>> > > resources in a class, done.
>> >
>> > Sorry, but I really don't follow this. It isn't until you drill down
>> > to the node level that you get to the level of detail necessary. For
>> > example, software A requires version X on server A, and software A
>> > requires version Y on server B. The only way I can see to do that it
>> > is to define it at the node level. Defining it at the class level is
>> > too far up the chain.
>>
>> You're not really talking about defining resources here. You can
>> specify node-specific variables when using an external node classifier,
>> and so you could use those to indicate node-specific requirements like
>> software versions.
>>
>> Ultimately an external node classifier has to provide these bits of YAML
>> to Puppet for each node:
>>
>> classes: [ <Puppet class names go here> ]
>> parameters: { <arbitrary variable=value settings go here> }
>>
>> So if you need different Apache versions on two different nodes, your
>> node classifier could supply this for node1:
>>
>> classes: [ apache-server ]
>> parameters: { apache_version=2.0.63 }
>>
>> and this for node2:
>>
>> classes: [ apache-server ]
>> parameters: { apache_version=2.2.15 }
>>
>> And then in each node $apache_version would indicate which version to
>> install, which you could use in a "package" resource or whatever.
>
> Steven,
>
> Trying to understand this, but let's say we had multiple instances of
> Apache running on each server (we actually have multiple instances of
> JBOSS and Tomcat running, but lets stick with Apache for the analogy).
>
> How would defining variables work then? I mean, your example above has:
>
> parameters: { apache_version=2.2.15 }
>
> Extending this, we'd end up using:
>
> parameters: { apache1_version=2.2.15, apache2_version=2.2.16,
> apache3_version=2.2.16, apache4_version=2.2.17 }
>
> and so on, depending on what the syntax is:
>
> HOWEVER, we also define a number of different parameters for each
> instance of software, which makes the whole set of parameters even
> more complicated. Do external nodes work in this case?
>
> Doug
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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.
