Puppet agent as WSDL service

[Kayode Odeyemi]

I will like to have puppet agent as WSDL service that can be consumed from an external application. I want to be able to have access to puppet agents via some URL from an external application.

Please how can I go about this?

--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde blog: http://sinati.com/tree/java-cheat-sheet

[Daniel Pittman]

On Tue, Sep 11, 2012 at 11:16 AM, Kayode Odeyemi <dre...@gmail.com> wrote:

> I will like to have puppet agent as WSDL service that can be consumed from
> an external application. I want to be able to have access to puppet agents
> via some URL from an external application.

We don't provide any WSDL descriptions of the network API, and it
seems unlikely that we ever would.

You can find documentation about the facilities exposed here:
http://docs.puppetlabs.com/guides/rest_api.html

We also don't expose much, if any, externally useful functionality
from the agent on the network. If you describe what you are trying to
achieve we can possibly help you work out how to achieve it.

(PS: the development list is generally better for these sort of questions.)

--
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

[Kayode Odeyemi]

On Tuesday, 11 September 2012 19:35:27 UTC+1, Daniel Pittman wrote:

On Tue, Sep 11, 2012 at 11:16 AM, Kayode Odeyemi <dre...@gmail.com> wrote:

> I will like to have puppet agent as WSDL service that can be consumed from
> an external application. I want to be able to have access to puppet agents
> via some URL from an external application.

I'm providing a management interface to manage DNS and other services running on nodes. Some of the things I want to be able to do from the management interface are;

• change network address
  
• change nameserver
• Install and configure DNS server
  
• Ping a host machine
• Install BIRD
  
• Start an instance of BIRD
  
• change domain name
• change hostname
• stop dns server
• start dns server

So from a click of a button I want to be able to start or stop a DNS server etc.

[Daniel Pittman]

That doesn't actually map super-well to the design of Puppet, since it
doesn't instantly react to change, it reacts on a schedule. You can
obviously make the latency low by running all the time, but it is
still non-zero.

The things you want to do are also not done by talking directly to the
agent - you do those by having the catalog that is compiled for the
node assert the things you want. So, you are really looking for a way
to configure catalog compilation to do what you want, not to talk to
the agent.

Take a look at the documentation on https://docs.puppetlabs.com/
around the DSL and modules to figure that out; the best match for what
you want is an ENC, or "External Node Classifier", which you would
have to provide yourself.


All that said, if you really want *instant* results, you want to look
at MCollective:
http://docs.puppetlabs.com/#mcollectivemcollective

[Kayode Odeyemi]

That doesn't actually map super-well to the design of Puppet, since it
doesn't instantly react to change, it reacts on a schedule.  You can
obviously make the latency low by running all the time, but it is
still non-zero.

The things you want to do are also not done by talking directly to the
agent - you do those by having the catalog that is compiled for the
node assert the things you want.  So, you are really looking for a way
to configure catalog compilation to do what you want, not to talk to
the agent.

Take a look at the documentation on https://docs.puppetlabs.com/
around the DSL and modules to figure that out; the best match for what
you want is an ENC, or "External Node Classifier", which you would
have to provide yourself.

I've heard this over-and-over. It just doesn't sink. I always see ENC to be useful
for getting out information and not modifying configuration or executing actions.

All that said, if you really want *instant* results, you want to look
at MCollective:
http://docs.puppetlabs.com/#mcollectivemcollective

I just figured out the architecture. MCollective + ActiveMQ.

So for each of the scenarios I want to create, I've decided to have a PHP code
that will call the Ruby client, which will then send the message to the broker.

Because filters are applied, this helps to identify the right node that matches the filters
in the message. Specific agent on the selected node can then be triggered for execution. 

[Daniel Pittman]

On Tue, Sep 11, 2012 at 2:16 PM, Kayode Odeyemi <dre...@gmail.com> wrote:
>> That doesn't actually map super-well to the design of Puppet, since it
>> doesn't instantly react to change, it reacts on a schedule. You can
>> obviously make the latency low by running all the time, but it is
>> still non-zero.
>>
>> The things you want to do are also not done by talking directly to the
>> agent - you do those by having the catalog that is compiled for the
>> node assert the things you want. So, you are really looking for a way
>> to configure catalog compilation to do what you want, not to talk to
>> the agent.
>>
>> Take a look at the documentation on https://docs.puppetlabs.com/
>> around the DSL and modules to figure that out; the best match for what
>> you want is an ENC, or "External Node Classifier", which you would
>> have to provide yourself.
>
> I've heard this over-and-over. It just doesn't sink. I always see ENC to be useful
> for getting out information and not modifying configuration or executing actions.

The flow of data would be this:

Your UI updates the ENC.
The ENC informs the Puppet master what classes to include.
The master sends a catalog to the agent.
The agent acts on that information. (eg: start or stop a service)

You could remotely execute `puppet resource` or `puppet apply` to
shortcut some of this, but the basic design is that you build a set of
manifests and modules that define "functionality", and then use
something - our DSL, or an ENC - to determine which functionality
applies to which machine.

>> All that said, if you really want *instant* results, you want to look
>> at MCollective:
>> http://docs.puppetlabs.com/#mcollectivemcollective
>
> I just figured out the architecture. MCollective + ActiveMQ.
>
> So for each of the scenarios I want to create, I've decided to have a PHP
> code
> that will call the Ruby client, which will then send the message to the
> broker.
>
> Because filters are applied, this helps to identify the right node that
> matches the filters
> in the message. Specific agent on the selected node can then be triggered
> for execution.

That sounds like a reasonable model. The Live Management facilities
we provide in Puppet Enterprise are built around the same basic
architecture, so we know that works well in the real world.

[Kayode Odeyemi]

Very very clear. Finally I got to understand it. Thank you.

>> All that said, if you really want *instant* results, you want to look
>> at MCollective:
>> http://docs.puppetlabs.com/#mcollectivemcollective
>
> I just figured out the architecture. MCollective + ActiveMQ.
>
> So for each of the scenarios I want to create, I've decided to have a PHP
> code
> that will call the Ruby client, which will then send the message to the
> broker.
>
> Because filters are applied, this helps to identify the right node that
> matches the filters
> in the message. Specific agent on the selected node can then be triggered
> for execution.

That sounds like a reasonable model.  The Live Management facilities
we provide in Puppet Enterprise are built around the same basic
architecture, so we know that works well in the real world.

Interesting. Thanks