Puppet users - Apr 2008 - Anyone disabling handlers in puppetmasterd?

Hi all,

I''m trying to decide my backward compatibility strategy for the xmlrpc
=> REST switch.  Currently, puppetmasterd provides the ability to  
disable different handlers, like reports, master, and the filebucket.  
(e.g., you ''d be doing --noreports or --nomaster)

I *think* no one is using this ability, so I''m planning on removing it
in 0.25.  Thus, if you''re using it, please let me know, and, of  
course, provide a good reason. :)

You''ll still have the ability to selectively disable the certificate  
authority; I think this is the only one used, which is why it was  
moved to being configured in the settings, rather than in  
puppetmasterd-specific cli options.  All other handlers will end up  
hard-coded somewhere; either in puppetmasterd, or directly in the  
plumbing that provides the compatibility.

Anyone have any problems with this?

-- 
Anyone who considers arithmatical methods of producing random digits
is, of course, in a state of sin. --John Von Neumann
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Luke Kanies schrieb:
> Hi all,
Hi Luke,
> 
> I''m trying to decide my backward compatibility strategy for the
xmlrpc
> => REST switch.  Currently, puppetmasterd provides the ability to  
> disable different handlers, like reports, master, and the filebucket.  
> (e.g., you ''d be doing --noreports or --nomaster)
> 
> I *think* no one is using this ability, so I''m planning on
removing it
> in 0.25.  Thus, if you''re using it, please let me know, and, of  
> course, provide a good reason. :)
I guess you''re right and nobody is currently really relying on that 
stuff. However, when using REST and Mongrel one would be able to 
configure the balancer to send specific requests (fileserver, 
filebucket, reports, whatever) to specific backends. This would be 
really great, because you could then offload specific workloads (e.g. 
fileserving) from your main puppetmaster without having to set up a 
complete puppetmaster on the other systems with all the requirements 
your setup might imply.
However, this usually means you want to disable the parts of 
puppetmasterd that are not served on these hosts.

So I guess these switches might finally become interesting once the move 
from XML-RPC to REST is finished and support for the current protocol is 
dropped (or can be disabled).
So I''d vote for "rethink if it really makes sense to disable
them".

Just my $ 0.02

Andreas

-- 
Solvention
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info@solvention.de

I''ve been quiet for a bit so here goes...

We use the reports to see "what needs changing" centrally.  So if we
update the manifest and a change ripples out to a few hundred hosts,
the reports show this clearly.

We use --no-report a lot, principally during the inital build (of a
new machine) process.  This is to avoid the reports coming up with a
tonne of "changes" which aren''t really changes in production.
We
don''t have any kind of flag to say that these machines are pre-
production and filter these messages out otherwise.

So this is actually a big deal for us.  Despite there being only a
little reporting infrastructure within Puppet, what there is is pretty
damn useful, and once you load the files into something that parses
them, you can extract a wealth of high-quality data.

Cheers,
Derek


On Apr 29, 8:03 am, Andreas Rogge <a.ro...@solvention.de>
wrote:
> Luke Kanies schrieb:
>
> > Hi all,
>
> Hi Luke,
>
>
>
> > I''m trying to decide my backward compatibility strategy for
the xmlrpc
> > => REST switch.  Currently, puppetmasterd provides the ability to
> > disable different handlers, like reports, master, and the filebucket.
> > (e.g., you ''d be doing --noreports or --nomaster)
>
> > I *think* no one is using this ability, so I''m planning on
removing it
> > in 0.25.  Thus, if you''re using it, please let me know, and,
of
> > course, provide a good reason. :)
>
> I guess you''re right and nobody is currently really relying on
that
> stuff. However, when using REST and Mongrel one would be able to
> configure the balancer to send specific requests (fileserver,
> filebucket, reports, whatever) to specific backends. This would be
> really great, because you could then offload specific workloads (e.g.
> fileserving) from your main puppetmaster without having to set up a
> complete puppetmaster on the other systems with all the requirements
> your setup might imply.
> However, this usually means you want to disable the parts of
> puppetmasterd that are not served on these hosts.
>
> So I guess these switches might finally become interesting once the move
> from XML-RPC to REST is finished and support for the current protocol is
> dropped (or can be disabled).
> So I''d vote for "rethink if it really makes sense to disable
them".
>
> Just my $ 0.02
>
> Andreas
>
> --
> Solvention
> Egermannstr. 6-8
> 53359 Rheinbach
>
> Tel: +49 2226 158179-0
> Fax: +49 2226 158179-9
>
> http://www.solvention.de
> mailto:i...@solvention.de
>
>  smime.p7s
> 4KDownload
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Not knowing a lot about this my first thought was to use environments
for this.  Would it be possible to have a "Pre-Production" environment
where you do your system construction and setup and then move it to
"Production" when its ready.  Again, I may be completely off base for
this but its a thought.

Later...
  Richard

On Apr 29, 8:05 am, DerekW <whaym...@gmail.com>
wrote:
> I''ve been quiet for a bit so here goes...
>
> We use the reports to see "what needs changing" centrally.  So if
we
> update the manifest and a change ripples out to a few hundred hosts,
> the reports show this clearly.
>
> We use --no-report a lot, principally during the inital build (of a
> new machine) process.  This is to avoid the reports coming up with a
> tonne of "changes" which aren''t really changes in
production.  We
> don''t have any kind of flag to say that these machines are pre-
> production and filter these messages out otherwise.
>
> So this is actually a big deal for us.  Despite there being only a
> little reporting infrastructure within Puppet, what there is is pretty
> damn useful, and once you load the files into something that parses
> them, you can extract a wealth of high-quality data.
>
> Cheers,
> Derek
>
> On Apr 29, 8:03 am, Andreas Rogge <a.ro...@solvention.de> wrote:
>
> > Luke Kanies schrieb:
>
> > > Hi all,
>
> > Hi Luke,
>
> > > I''m trying to decide my backward compatibility strategy
for the xmlrpc
> > > => REST switch.  Currently, puppetmasterd provides the ability
to
> > > disable different handlers, like reports, master, and the
filebucket.
> > > (e.g., you ''d be doing --noreports or --nomaster)
>
> > > I *think* no one is using this ability, so I''m planning
on removing it
> > > in 0.25.  Thus, if you''re using it, please let me know,
and, of
> > > course, provide a good reason. :)
>
> > I guess you''re right and nobody is currently really relying
on that
> > stuff. However, when using REST and Mongrel one would be able to
> > configure the balancer to send specific requests (fileserver,
> > filebucket, reports, whatever) to specific backends. This would be
> > really great, because you could then offload specific workloads (e.g.
> > fileserving) from your main puppetmaster without having to set up a
> > complete puppetmaster on the other systems with all the requirements
> > your setup might imply.
> > However, this usually means you want to disable the parts of
> > puppetmasterd that are not served on these hosts.
>
> > So I guess these switches might finally become interesting once the
move
> > from XML-RPC to REST is finished and support for the current protocol
is
> > dropped (or can be disabled).
> > So I''d vote for "rethink if it really makes sense to
disable them".
>
> > Just my $ 0.02
>
> > Andreas
>
> > --
> > Solvention
> > Egermannstr. 6-8
> > 53359 Rheinbach
>
> > Tel: +49 2226 158179-0
> > Fax: +49 2226 158179-9
>
> >http://www.solvention.de
> > mailto:i...@solvention.de
>
> >  smime.p7s
> > 4KDownload
--~--~---------~--~----~------------~-------~--~----~
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, 2008, at 2:03 AM, Andreas Rogge wrote:
>
> I guess you''re right and nobody is currently really relying on
that
> stuff. However, when using REST and Mongrel one would be able to  
> configure the balancer to send specific requests (fileserver,  
> filebucket, reports, whatever) to specific backends. This would be  
> really great, because you could then offload specific workloads  
> (e.g. fileserving) from your main puppetmaster without having to set  
> up a complete puppetmaster on the other systems with all the  
> requirements your setup might imply.
> However, this usually means you want to disable the parts of  
> puppetmasterd that are not served on these hosts.
>
> So I guess these switches might finally become interesting once the  
> move from XML-RPC to REST is finished and support for the current  
> protocol is dropped (or can be disabled).
> So I''d vote for "rethink if it really makes sense to disable
them".
All I''m really worried about right now is the xmlrpc backward  
compatibility support.

I agree, this kind of configurability will be very helpful.  I doubt  
it will make it into the first release -- my goal is feature  
completeness first of all, and then we can later add configurability  
as people demand it.

-- 
I have an answering machine in my car. It says, "I''m home now. But
leave a message and I''ll call when I''m out. -- Stephen Wright
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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, 2008, at 7:05 AM, DerekW wrote:
>
> I''ve been quiet for a bit so here goes...
>
> We use the reports to see "what needs changing" centrally.  So if
we
> update the manifest and a change ripples out to a few hundred hosts,
> the reports show this clearly.
>
> We use --no-report a lot, principally during the inital build (of a
> new machine) process.  This is to avoid the reports coming up with a
> tonne of "changes" which aren''t really changes in
production.  We
> don''t have any kind of flag to say that these machines are pre-
> production and filter these messages out otherwise.
>
> So this is actually a big deal for us.  Despite there being only a
> little reporting infrastructure within Puppet, what there is is pretty
> damn useful, and once you load the files into something that parses
> them, you can extract a wealth of high-quality data.

This is actually client-side, and this ability will stay.

Sorry, I should have been clear on that -- I''m only worried right now  
about whether we should retain the ability to configure which handlers  
are served via xmlrpc on the server.  Sending reports is a client-side  
option, and has no affect on what services are available anywhere.

-- 
Life is like playing a violin in public and learning the instrument as
one goes on. -- Samuel Butler
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Works for me :-)

On Apr 29, 2:49 pm, Luke Kanies <l...@madstop.com>
wrote:
> On Apr 29, 2008, at 7:05 AM, DerekW wrote:
>
>
>
>
>
> > I''ve been quiet for a bit so here goes...
>
> > We use the reports to see "what needs changing" centrally. 
So if we
> > update the manifest and a change ripples out to a few hundred hosts,
> > the reports show this clearly.
>
> > We use --no-report a lot, principally during the inital build (of a
> > new machine) process.  This is to avoid the reports coming up with a
> > tonne of "changes" which aren''t really changes in
production.  We
> > don''t have any kind of flag to say that these machines are
pre-
> > production and filter these messages out otherwise.
>
> > So this is actually a big deal for us.  Despite there being only a
> > little reporting infrastructure within Puppet, what there is is pretty
> > damn useful, and once you load the files into something that parses
> > them, you can extract a wealth of high-quality data.
>
> This is actually client-side, and this ability will stay.
>
> Sorry, I should have been clear on that -- I''m only worried right
now
> about whether we should retain the ability to configure which handlers
> are served via xmlrpc on the server.  Sending reports is a client-side
> option, and has no affect on what services are available anywhere.
>
> --
> Life is like playing a violin in public and learning the instrument as
> one goes on. -- Samuel Butler
> ---------------------------------------------------------------------
> Luke Kanies |http://reductivelabs.com|http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---