On Wednesday, September 5, 2012 4:35:45 PM UTC-5, am-aaron wrote:
>
> hello Jenner:
>
> thank you.
>
> without intending to be rude or scornful: using MCollective?
>
Meaning that you will be at least scornful, and we're supposed to let it
slide? I'd rather you just be scornful than disingenuous.
> hmmm. instead, i can use a simple shell script, and it works great in
> minutes. Puppet makes us go bonkers and i do not think its really intuitive
> to understand. instead a procedural scipt is just great.
>
If a procedural script does the job satisfactorily for you, then why are
you trying to make Puppet do it?
Puppet does not do orchestration. It was not designed to do, and as far as
I know there are no plans to introduce orchestration features into any
future version. It is not Puppet's problem that it is the wrong tool for
your job.
With that said, if you want an automated orchestration solution, then there
are several available, one of them being PuppetLabs's own MCollective.
As far as Puppet being easy to understand, you really have to look at it
from the correct perspective. Your description of what you want Puppet to
do ("install", "run", "configure") suggests that you're focusing on the
wrong things. Puppet is not a scripting engine, or anything like one, so
if you focus on *actions* you want to perform then you will indeed have a
tough time of it. Instead, Puppet is a state management system, so to
understand it you need to focus on the system state you want to achieve and
maintain. Generally speaking, the actions performed if any to transition
from the current state to the desired state are incidental to Puppet, at
least from the view of the manifest author.
So if you find yourself thinking about Puppet in terms of verbs (i.e.
"Puppet should [perform some action]") then you are probably looking at it
the wrong way. You should instead be thinking in terms of adjectives:
"present", "installed", "running", etc.. Also, if you're looking to use
Puppet to apply some change to your systems that you're not afterward going
to *maintain* via Puppet, then you are probably trying to use the wrong
tool.
>
> i find this restriction very strange, though i understood recently that
> you use Puppet to declare how a system should be.
>
Your issue in fact follows directly from Puppet's nature. It is because
Puppet focuses on state (of individual nodes) instead of on transitions
that it is not much good for orchestration. Orchestration is all about
coordinating actions.
> i have a problem: i want to install a software package on multiple nodes
> and then have to run a configure program to configure all the nodes. its
> not distributing configuration files, i have to run the program only on 1
> of the nodes or from a separate machine. its not easy to synchronize all
> the nodes and to ensure that all machines are in the same state before you
> run the configure.
>
Indeed, it is very difficult to do that with Puppet. There's an old joke
about a man who goes to the doctor and complains, "Doc, it hurts when I do
<this>." Says the doctor: "Then don't do that!"
I can think of at least one approach to achieve your specific goal via
Puppet, but it would be complicated and ugly. Don't do that!
>
> instead, it damn easy to run the Install and Configure from a single
> machine to all the Nodes. no synchronization problems and one manifest to
> maintain.
>
And afterward, to avoid needlessly (or wrongly) doing that again?
>
> Puppet also has big issues with this scenario: from one machine to check
> the status of a file on another machine and to then take action. the File{}
> resource only applies to the local machine.
>
Exported resources can be used to achieve some objectives of this kind.
> so, how do i do distributed system admin or remote sys admin?
>
As I usually interpret those terms, that is *exactly* what MCollective and
similar tools are for. Or 'ssh -c' if you want to be minimalistic.
>
> i spend so much time to learn Puppet, we pay a good deal for it, and we
> spend some time to understand how to use the declarative language, but i
> cannot do simple things.
>
Again, you are approaching Puppet the wrong way. Most system
administration tasks have this general form:
1. Check whether the target system is in the correct state with respect
to <foo>
2. If not, then take the appropriate action to achieve the desired state
3. Some time later, go back to 1
Puppet allows (in fact demands that) you focus on the target state in your
manifests. That is, you describe where you want to be, not how you want to
get there. Puppet is pretty good at figuring out the latter for itself.
> even doing an 'echo' to log output is so complicated.
>
Once more, "doing [...]." If you want a custom message to appear in the
Puppet's agent's log, then that's what Notify resources represent.
I hesitate even to mention it, as I am concerned that you will make trouble
for yourself, but ultimately, Puppet's Exec resource allows it to do
absolutely anything for which it has sufficient privilege. Don't shoot too
many toes off.
> if we have to resort to using Ruby, its even more complicated. enhances my
> qualifications, but is it that vital to use it?
>
Of course not. You should always choose the right tool for the job, and
there are plenty of jobs for which that tool is not Puppet. On the other
hand, there are many, many jobs for which Puppet is a great tool. If
you're learning it merely to enhance your qualifications then you are
completely missing the boat. You should be using it because (and where) it
makes your job and life easier.
John
--
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/-/fQhWjlkk_swJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
