Puppet 4 : questions about PXP agent and its goal

[Francois Lafont]

Hello and happy new year @all ;)

I have discovered recently the presence of the service "pxp-agent" after
the installation of the AIO package "puppet-agent". Personally, in the
puppet client side, I'm using the puppet-agent to contact the open source
puppetserver (so it's puppet 4, and personally I absolutely don't know PE)
and the mcollective server (which contacts a middleware). That's all.

1. Is it possible for me to disable the pxp-agent service (so that the
service doesn't start on boot) in my servers without problem? Or is the
"pxp-agent" service necessary in my case?

I have made an attempt in one server and apparently there no problem, the
service seems to be completely useless in my case. Am I wrong? Furthermore,
after the installation of puppet-agent, I don't see a listening port for
the service "pxp-agent".

2. If I understand well, pxp-agent seems to be something like mcollective.
Does it mean that the mcollective project will be abandoned and replaced
one day by the pxp-agent service? It will be curious because mcollective is
already included in the AIO package puppet-agent. So maybe pxp-agent and
mcollective will coexist together but in this case I don't really see the
difference between these tools (as regards the purpose of these tools).

Thanks for your help.
Regards.

--
François Lafont

[Ryan Coleman]

On Sunday, January 3, 2016 at 4:37:05 PM UTC-8, François Lafont wrote:

Hello and happy new year @all ;)

I have discovered recently the presence of the service "pxp-agent" after
the installation of the AIO package "puppet-agent". Personally, in the
puppet client side, I'm using the puppet-agent to contact the open source
puppetserver (so it's puppet 4, and personally I absolutely don't know PE)
and the mcollective server (which contacts a middleware). That's all.

Hello and happy new year to you as well, 

 

1. Is it possible for me to disable the pxp-agent service (so that the
service doesn't start on boot) in my servers without problem? Or is the
"pxp-agent" service necessary in my case?

I have made an attempt in one server and apparently there no problem, the
service seems to be completely useless in my case. Am I wrong? Furthermore,
after the installation of puppet-agent, I don't see a listening port for
the service "pxp-agent".

In my CentOS 7 install of puppet-agent 1.3.2, the pxp-agent service is not enabled or started by default. You can safely disable it without impacting the operations of Puppet. 

# /opt/puppetlabs/bin/puppet resource service pxp-agent ensure=stopped enable=false

# /opt/puppetlabs/bin/puppet resource service pxp-agent

service { 'pxp-agent':

  ensure => 'stopped',

  enable => 'false',

}

 

2. If I understand well, pxp-agent seems to be something like mcollective.
Does it mean that the mcollective project will be abandoned and replaced
one day by the pxp-agent service? It will be curious because mcollective is
already included in the AIO package puppet-agent. So maybe pxp-agent and
mcollective will coexist together but in this case I don't really see the
difference between these tools (as regards the purpose of these tools).

As you noticed, there's no listening service for pxp-agent. Think of it more like a modern puppet-kick than a replacement for MCollective. In Puppet Enterprise 2015.3, it's configured to connect to its broker and wait for instructions like start a puppet run or inspect the state of the last run. It's capable of doing more than this but that's its purpose today; a light-weight way for puppet-server infrastructure to have more direct control of when an agent enforces new configuration without changing how the puppet-agent operates. We use this for the new orchestration service and web console run puppet controls in PE. It will coexist with MCollective until (and if) there's a compelling reason for them to converge. For example, we don't provide extension APIs for PXP like you get with MCollective. It's intended only for programmatic control of the puppet-agent, today.  

The broker [1], agent [2] and client libraries [3] are open-source for those not running PE but I'm not aware of anything using it beyond PE (yet).

[1] https://github.com/puppetlabs/pcp-broker

[2] https://github.com/puppetlabs/pxp-agent

[3] https://github.com/puppetlabs/cpp-pcp-client https://github.com/puppetlabs/clj-pcp-client https://github.com/puppetlabs/ruby-pcp-client

Thanks for your help.

Thanks for the mail. Cheers. 

--Ryan, product manager @puppetlabs 

[Francois Lafont]

Hi,

On 04/01/2016 20:44, Ryan Coleman wrote:

> Hello and happy new year to you as well,

Thanks, ;)

> In my CentOS 7 install of puppet-agent 1.3.2, the pxp-agent service is not
> enabled or started by default.

Ok. I have noticed that in Debian Jessie too.
But in Ubuntu Trusty, the pxp-agent daemon seems enabled by default.

> You can safely disable it without impacting the operations of Puppet.

Ok. I'm going to do that in this case (I have several Trusty servers).

> As you noticed, there's no listening service for pxp-agent. Think of it
> more like a modern puppet-kick than a replacement for MCollective. In
> Puppet Enterprise 2015.3, it's configured to connect to its broker and wait
> for instructions like start a puppet run or inspect the state of the last
> run. It's capable of doing more than this but that's its purpose today; a
> light-weight way for puppet-server infrastructure to have more direct
> control of when an agent enforces new configuration without changing how
> the puppet-agent operates. We use this for the new orchestration service
> and web console run puppet controls in PE. It will coexist with MCollective
> until (and if) there's a compelling reason for them to converge. For
> example, we don't provide extension APIs for PXP like you get with
> MCollective. It's intended only for programmatic control of the
> puppet-agent, today.

Ok I see.

> The broker [1], agent [2] and client libraries [3] are open-source for
> those not running PE but I'm not aware of anything using it beyond PE (yet).
>
> [1] https://github.com/puppetlabs/pcp-broker
> [2] https://github.com/puppetlabs/pxp-agent
> [3] https://github.com/puppetlabs/cpp-pcp-client https://github.com/puppetlabs/clj-pcp-client https://github.com/puppetlabs/ruby-pcp-client

Ok, that's clear for me now. Thanks for all these explanations. ;)
Regards.

François Lafont

[Kylo Ginsberg]

On Wed, Jan 6, 2016 at 4:15 PM, Francois Lafont <francois.l...@gmail.com> wrote:

Hi,

On 04/01/2016 20:44, Ryan Coleman wrote:

> Hello and happy new year to you as well,

Thanks, ;)

> In my CentOS 7 install of puppet-agent 1.3.2, the pxp-agent service is not
> enabled or started by default.

Ok. I have noticed that in Debian Jessie too.
But in Ubuntu Trusty, the pxp-agent daemon seems enabled by default.

Hmm, pretty sure that inconsistency was unintentional. I filed https://tickets.puppetlabs.com/browse/PA-141 to track that.

Kylo

 

> You can safely disable it without impacting the operations of Puppet.

Ok. I'm going to do that in this case (I have several Trusty servers).

> As you noticed, there's no listening service for pxp-agent. Think of it
> more like a modern puppet-kick than a replacement for MCollective. In
> Puppet Enterprise 2015.3, it's configured to connect to its broker and wait
> for instructions like start a puppet run or inspect the state of the last
> run. It's capable of doing more than this but that's its purpose today; a
> light-weight way for puppet-server infrastructure to have more direct
> control of when an agent enforces new configuration without changing how
> the puppet-agent operates. We use this for the new orchestration service
> and web console run puppet controls in PE. It will coexist with MCollective
> until (and if) there's a compelling reason for them to converge. For
> example, we don't provide extension APIs for PXP like you get with
> MCollective. It's intended only for programmatic control of the
> puppet-agent, today.

Ok I see.

> The broker [1], agent [2] and client libraries [3] are open-source for
> those not running PE but I'm not aware of anything using it beyond PE (yet).
>
> [1] https://github.com/puppetlabs/pcp-broker
> [2] https://github.com/puppetlabs/pxp-agent
> [3] https://github.com/puppetlabs/cpp-pcp-client https://github.com/puppetlabs/clj-pcp-client https://github.com/puppetlabs/ruby-pcp-client

Ok, that's clear for me now. Thanks for all these explanations. ;)
Regards.

François Lafont

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/568DAE23.6090507%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Kylo Ginsberg | ky...@puppetlabs.com | irc: kylo | twitter: @kylog

[Stefan Heijmans]

On Monday, January 4, 2016 at 8:44:12 PM UTC+1, Ryan Coleman wrote:

The broker [1], agent [2] and client libraries [3] are open-source for those not running PE but I'm not aware of anything using it beyond PE (yet).

And what about this [1]?

"A little further down the line, Puppet Labs will create a simplified version that will be open sourced and paired with the open version of the base Puppet tool. The Application Orchestration feature will be rolled out in the Puppet Enterprise 2015.3 update later this year, so presumably this open source variant will be let loose sometime in early 2016."

[1] http://www.nextplatform.com/2015/10/05/puppet-takes-orchestration-up-the-stack-to-apps/