Puppet Sites. Your thoughts?

[Daniel Sauble]

Hey all,

I've been designing a new feature for Puppet, and wanted to get some kick-back from the community to see if you think this is needed or not. The feature is called Puppet Sites, and meets some specific goals by means of a few tasks.

• Securely add nodes to your deployment without manually signing certificates on the CA...
• ...so that you can have the advantages of autosigning without its security problems.

• Get a list of all the nodes in your deployment...
• ...so that a single command can give you what previously you had to trawl multiple services (ENCs, CAs, etc...) on each Puppet master in your deployment to retrieve.

• Store connection information for Puppet services in a central location (accessible from manifests, puppet.conf, and defaults.rb)...
• ...so that you don't have to manage puppet.conf files on each node in your population
• ...so that agent/master/CA configuration stays consistent across your deployment
• ...so that you can update your config and fetch a new catalog in a single operation.

Thanks in advance for the feedback!

- Daniel

[Kelsey Hightower]

On Thu, May 10, 2012 at 12:44 PM, Daniel Sauble <djsa...@puppetlabs.com> wrote:

Hey all,

I've been designing a new feature for Puppet, and wanted to get some kick-back from the community to see if you think this is needed or not. The feature is called Puppet Sites, and meets some specific goals by means of a few tasks.

• Securely add nodes to your deployment without manually signing certificates on the CA...
• ...so that you can have the advantages of autosigning without its security problems.

• Get a list of all the nodes in your deployment...
• ...so that a single command can give you what previously you had to trawl multiple services (ENCs, CAs, etc...) on each Puppet master in your deployment to retrieve.

 How does this work with ENCs? Will the ENC need to talk to Puppet sites for node information such as environment settings? When nodes are added and removed from Puppet sites will they be updated in the ENC and vice-versa.

• Store connection information for Puppet services in a central location (accessible from manifests, puppet.conf, and defaults.rb)...
• ...so that you don't have to manage puppet.conf files on each node in your population
• ...so that agent/master/CA configuration stays consistent across your deployment
• ...so that you can update your config and fetch a new catalog in a single operation.

So will each node then need to be configured with the location to Puppet sites?

 

Thanks in advance for the feedback!

- Daniel

--
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/-/cdG9GFFqvYEJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Kelsey Hightower

Developer

Puppet Labs

(678) 4719501

[Romeo Theriault]

Hi Daniel, thanks for dropping a note to get some feedback on this.
While these features sound very nice I personally would find it
interesting and might have more to add if you went into a bit of
detail about how you plan to implement these features.

Thanks,

--
Romeo

[Daniel Sauble]

On Thursday, May 10, 2012 9:53:15 AM UTC-7, Kelsey Hightower wrote:

On Thu, May 10, 2012 at 12:44 PM, Daniel Sauble <djsa...@puppetlabs.com> wrote:

Hey all,

I've been designing a new feature for Puppet, and wanted to get some kick-back from the community to see if you think this is needed or not. The feature is called Puppet Sites, and meets some specific goals by means of a few tasks.

• Securely add nodes to your deployment without manually signing certificates on the CA...
• ...so that you can have the advantages of autosigning without its security problems.

• Get a list of all the nodes in your deployment...
• ...so that a single command can give you what previously you had to trawl multiple services (ENCs, CAs, etc...) on each Puppet master in your deployment to retrieve.

 How does this work with ENCs? Will the ENC need to talk to Puppet sites for node information such as environment settings? When nodes are added and removed from Puppet sites will they be updated in the ENC and vice-versa.

Puppet Sites includes three services: a node registry, a service registry, and an authentication service.

The node registry in the MVP for Puppet Sites is a slightly-modified CA (the sole difference being that certificates cannot be revoked from the node registry without the node itself leaving the site). So no, there isn't any communication between the node registry and the ENC.

However, the ENC can use the service registry to discover where the node registry lives, and do polling to update its own classification data.

• Store connection information for Puppet services in a central location (accessible from manifests, puppet.conf, and defaults.rb)...
• ...so that you don't have to manage puppet.conf files on each node in your population
• ...so that agent/master/CA configuration stays consistent across your deployment
• ...so that you can update your config and fetch a new catalog in a single operation.

So will each node then need to be configured with the location to Puppet sites?

Yes. The goal is that each agent only require a single configuration parameter (site_server, perhaps), and the agent be able to automatically connect to all Puppet services specified in the Site's service registry.

 

 

Thanks in advance for the feedback!

- Daniel

--
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/-/cdG9GFFqvYEJ.
To post to this group, send email to puppet...@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.

[Daniel Sauble]

At this point, I'm trying to elicit feedback around user needs and desires, without tying 

the discussion to implementation details. If any of these goals don't seem particularly 

interesting to you, or if you have any goals I haven't addressed, or if you need clarification

around what I mean in any of my bullet points, I'd love to hear what you think.

 

Thanks,

--
Romeo

[windowsrefund]

On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote:
>
>    - Securely add nodes to your deployment without manually signing
>    certificates on the CA...
>       - ...so that you can have the advantages of autosigning without its
>       security problems.
>

I'm about to engage on a similar effort and was thinking of writing a
puppet face to handle this job. Can you elaborate on the work flow and
solution you're thinking about?

>    - Get a list of all the nodes in your deployment...
>       - ...so that a single command can give you what previously you had to

>       trawl multiple services (ENCs, CAs, etc...) on each Puppet master in your
>       deployment to retrieve.
>

Personally, I have no interest in logging into my puppet servers and
running commands. It seems like this problem is better solved with a
real monitoring solution.

Best,

Adam

[Deepak Giridharagopal]

On Thu, May 10, 2012 at 11:39 AM, windowsrefund <window...@gmail.com> wrote:

Personally, I have no interest in logging into my puppet servers and
running commands. It seems like this problem is better solved with a
real monitoring solution.

Our intent is to expose this information via APIs that allow for easier integration with existing systems. In particular, we've been thinking about supporting the registration of listeners that get notified when nodes are added or removed from a site. That said, I share your sentiment that this is not a replacement for monitoring systems; conceptually, I view this piece of Sites much more as an mild evolution of the existing CA code.

deepak

--
Deepak Giridharagopal / Puppet Labs

[Daniel Sauble]

On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote:

On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote:
>
>    - Securely add nodes to your deployment without manually signing
>    certificates on the CA...
>       - ...so that you can have the advantages of autosigning without its
>       security problems.
>

I'm about to engage on a similar effort and was thinking of writing a
puppet face to handle this job. Can you elaborate on the work flow and
solution you're thinking about?

We're looking to implement a Puppet Face to address this need. The workflow currently looks like:

1. Login to the site host
2. Generate a pre-shared key
3. Join a node to the site using the pre-shared key
4. Repeat step 3 for every node you want to add to the site

From the command-line, this workflow might be represented as the following:

node02$ ssh ad...@site02.domain.com
Last login: Mon May  7 18:15:43 2012
site02$ mount /media/usbdisk
site02$ puppet site generate key > /media/usbdisk/site.key
site02$ umount /media/usbdisk
site02$ exit
node02$ mount /media/usbdisk
node02$ puppet node join site02.domain.com < /media/usbdisk/site.key
Trying to add node02.domain.com to the site at site02.domain.com...

Use `puppet site status node02.domain.com` to confirm success

To stop waiting for the command to complete, press Ctrl-C.

  The command will still complete in the background.

Added node02.domain.com to the site at site02.domain.com

[Ohad Levy]

will you allow the older workflow to co exists? would it be possible to drive all of the process via an external api?

thanks,

Ohad

--
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/-/dWo3QflKMogJ.

To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[R.I.Pienaar]

----- Original Message -----
> From: "Daniel Sauble" <djsa...@puppetlabs.com>
> To: puppet...@googlegroups.com
> Sent: Thursday, May 10, 2012 7:34:14 PM
> Subject: [Puppet Users] Re: Puppet Sites. Your thoughts?
>
> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote:
>
>
> On May 10, 12:44 pm, Daniel Sauble < djsau...@puppetlabs.com > wrote:
> >
> > - Securely add nodes to your deployment without manually signing
> > certificates on the CA...
> > - ...so that you can have the advantages of autosigning without its
> > security problems.
> >
>
> I'm about to engage on a similar effort and was thinking of writing a
> puppet face to handle this job. Can you elaborate on the work flow
> and
> solution you're thinking about?
>
>
>
> We're looking to implement a Puppet Face to address this need. The
> workflow currently looks like:
>
>
>

> 1. Login to the site host
> 2. Generate a pre-shared key
> 3. Join a node to the site using the pre-shared key
> 4. Repeat step 3 for every node you want to add to the site

>
>
>
> From the command-line, this workflow might be represented as the
> following:
>
> node02$ ssh ad...@site02.domain.com
> Last login: Mon May 7 18:15:43 2012
> site02$ mount /media/usbdisk
> site02$ puppet site generate key > /media/usbdisk/site.key
> site02$ umount /media/usbdisk
> site02$ exit
> node02$ mount /media/usbdisk
> node02$ puppet node join site02.domain.com < /media/usbdisk/site.key
> Trying to add node02.domain.com to the site at site02.domain.com...
>
>
> Use `puppet site status node02.domain.com` to confirm success
>
> To stop waiting for the command to complete, press Ctrl-C.
>
> The command will still complete in the background. Added
> node02.domain.com to the site at site02.domain.com

Can you explain the advantages this workflow has over the current process
involving requesting a cert and signing it on the master?

It would also be great if you could send plain text mail as is the convention
on this list.

[Daniel Sauble]

No, at present we are looking to deprecate the 'clean', 'generate', 'list', 'revoke', and 'sign' actions of 

the puppet cert face. The reason for this is we want the semantics of the user interface to match the

user need. The impression I've gotten (and feel free to chime in) is that users don't want to sign 

certificates, they want to add nodes to their deployment.

Yes, the goal is that all the functionality of the Puppet Face will also be available via the REST API.

[jcbollinger]

On May 10, 2:04 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote:
> On Thursday, May 10, 2012 11:37:34 AM UTC-7, ohad wrote:
>

> > On Thu, May 10, 2012 at 9:34 PM, Daniel Sauble <djsau...@puppetlabs.com>wrote:
>
> >> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote:
>
> >>> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote:
>
> >>> >    - Securely add nodes to your deployment without manually signing
> >>> >    certificates on the CA...
> >>> >       - ...so that you can have the advantages of autosigning without
> >>> its
> >>> >       security problems.
>
> >>> I'm about to engage on a similar effort and was thinking of writing a
> >>> puppet face to handle this job. Can you elaborate on the work flow and
> >>> solution you're thinking about?
>
> >> We're looking to implement a Puppet Face to address this need. The
> >> workflow currently looks like:
>

> >>    1. Login to the site host
> >>    2. Generate a pre-shared key

> >>    3. Join a node to the site using the pre-shared key
> >>    4. Repeat step 3 for every node you want to add to the site

>
> >> From the command-line, this workflow might be represented as the
> >> following:

> >> *

> >> node02$ ssh ad...@site02.domain.com
> >> Last login: Mon May  7 18:15:43 2012
> >> site02$ mount /media/usbdisk
> >> site02$ puppet site generate key > /media/usbdisk/site.key
> >> site02$ umount /media/usbdisk
> >> site02$ exit
> >> node02$ mount /media/usbdisk
> >> node02$ puppet node join site02.domain.com < /media/usbdisk/site.key
> >> Trying to add node02.domain.com to the site at site02.domain.com...
>
> >> Use `puppet site status node02.domain.com` to confirm success
>
> >> To stop waiting for the command to complete, press Ctrl-C.
>
> >>   The command will still complete in the background.

> >> Added node02.domain.com to the site at site02.domain.com*

>
> > will you allow the older workflow to co exists? would it be possible to
> > drive all of the process via an external api?
>
> No, at present we are looking to deprecate the 'clean', 'generate', 'list',
> 'revoke', and 'sign' actions of
> the puppet cert face. The reason for this is we want the semantics of the
> user interface to match the
> user need. The impression I've gotten (and feel free to chime in) is that
> users don't want to sign
> certificates, they want to add nodes to their deployment.

And remove them, and swap them for different physical nodes with the
same name, and change the names of existing physical nodes, and maybe
other things.

It's one thing to provide easy ways to do things people often want to
do. It's an altogether different thing to take away people's tools
for doing unusual things, or to make them jump through hoops to do
things that ought to be easy. Text interfaces are far more expressive
than any other kind, and they are easy to integrate with other tools.
That's the Unix way. By all means, provide all the convenience
features and alternative interfaces you think people would like, but
don't take away my CLI.


John

[Marc Zampetti]

Does this require that a human being has to be in the loop every time a node joins the site? How would one automate 100% the provisioning of new hosts? With the current system, I can turn on auto-sign and have some simple rules for which nodes I will accept, and trust in the knowledge that I have already ensured my network is secure enough to accept the risk of auto-signing. With that, I can automatically take a bare-metal server, and provision it all the way up to taking traffic without having anyone else involved. From the example above, having to generate the key on the master before I can provision puppet on the node seems to make that much more difficult.

Also, it would be good if you specify the issues that Sites is trying to solve in more detail. From my viewpoint, I don't have any issues with the current CA-based model. So I'm struggling to understand what you are trying to "fix". I'm sure I'm not alone, and I am assuming that I missing some details, so putting a more detailed description of the problems that the community is encountering, and how Sites would solve those would help with the discussion.

[Daniel Sauble]

I'd like to emphasize that this is purely a change in semantics. Let me elaborate

a bit about what the deprecation of these `puppet cert` actions entails, and feel free

to push back if you're still concerned. I apologize for the terseness of my 

deprecation post.

puppet cert fingerprint

puppet cert print

puppet cert verify

(these commands remain as is)

puppet cert generate

(replaced by `puppet site add`)

puppet cert list

(replaced by `puppet site list nodes`)

puppet cert revoke

(replaced by `puppet site remove`)

puppet cert sign

(replaced by `puppet site accept`)

puppet cert clean

This command doesn't map cleanly to sites. In Puppet as it exists today, removing

a certificate from the CA doesn't revoke permission to talk to other Puppet services.

In Puppet Sites, removing a node from the site revokes permission for that node

to ask the site where other Puppet services live. Because of this, we're replacing this 

with two commands (one being the replacement for `puppet cert revoke`):

puppet site reject (reject a node's request to join the site)

puppet site remove (remove a node from the site)

In Puppet Sites, nodes are still identified by their certname. With the exception of a 

slight behavior change to the CA--so it can serve as the authoritative source of information

about which nodes are in your site--the deprecation of these CA actions is a deprecation of

semantics, not functionality.

I'm happy to elaborate on the mental model these replacement commands are designed

to support.

- Daniel

[Kelsey Hightower]

I guess what people really want to know is: Will they be able to use auto-signing? Will auto-signing still work like it does today?

I see the advantages for people who never intend to use auto-signing, but the people who have accepted the risk do want to lose the "functionality" of auto-signing.

 

--
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/-/W9hQXvYw3v8J.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Daniel Sauble]

On Friday, May 11, 2012 5:56:10 AM UTC-7, Marc Zampetti wrote:

Does this require that a human being has to be in the loop every time a node joins the site? How would one automate 100% the provisioning of new hosts? With the current system, I can turn on auto-sign and have some simple rules for which nodes I will accept, and trust in the knowledge that I have already ensured my network is secure enough to accept the risk of auto-signing. With that, I can automatically take a bare-metal server, and provision it all the way up to taking traffic without having anyone else involved. From the example above, having to generate the key on the master before I can provision puppet on the node seems to make that much more difficult.

We don't want Puppet admins to have to trust that their network is secure. What Puppet Sites provides (among other things) is a PSK system that allows you to generate multiple-use keys for securely joining nodes to your site. In the provisioning case, you could generate a pre-shared key, bake it into your install tarball, and use that tarball to install Puppet and add each node to your site without human intervention. When you're done installing, you can revoke the PSK so it can't be used anymore. This gets you the convenience of autosigning with the confidence that even if your network is compromised, your Puppet deployment won't be.

But note that you can still use autosigning if you don't want to mess with pre-shared keys, or if you trust your network. We're just providing an alternative, not a replacement.

If you want to manually execute `puppet site accept` for each node that tries to join your site, you can do that too.

 

Also, it would be good if you specify the issues that Sites is trying to solve in more detail. From my viewpoint, I don't have any issues with the current CA-based model. So I'm struggling to understand what you are trying to "fix". I'm sure I'm not alone, and I am assuming that I missing some details, so putting a more detailed description of the problems that the community is encountering, and how Sites would solve those would help with the discussion.

One problem is that there isn't an authoritative source of information about which nodes are in your deployment. The CA comes close, but since you can remove the certificates of managed nodes, it doesn't fit the bill. That's one thing that Puppet Sites gets you. The ability to run a single command and know with certainty which nodes you're managing.

Another problem is that if you move services around, you have to update puppet.conf on all nodes that use that service. For example, if you migrate your master to a new host, you have to update puppet.conf on every agent that uses that master. What Puppet Sites provides is a service registry that allows you to store this information in a central location. Your agents retrieve service connection information from the service registry. So, if your master switches to a different host, all you need do is update the host in the service registry, and all your agents will pick up that change automatically.

[Timothy Sutton]

Just concerning this PSK aspect of Sites, would this also be a similar alternative to using a shared cert (or set of certs) in tandem with the node_name_value or node_name_fact, as was recently suggested by Gary in this thread?

https://groups.google.com/d/msg/puppet-users/2s0PJ7p_S7M/jLVUjL34Wz4J

We're just evaluating Puppet now, but I'd considered using this strategy with my cert(s) to allow me to more freely deploy/recycle nodes and with one less human involved.

Tim

[Timothy Sutton]

Just concerning this PSK aspect of Sites, would this also be a similar alternative to using a shared cert (or set of certs) in tandem with the node_name_value or node_name_fact, as was recently discussed in this thread?

https://groups.google.com/d/msg/puppet-users/2s0PJ7p_S7M/jLVUjL34Wz4J

In evaluating our implementation strategy for Puppet, I'd considered using this method to allow me to more freely deploy/recycle nodes and with one less human involved.

Tim

[Daniel Sauble]

On Saturday, May 12, 2012 6:14:06 AM UTC-7, Timothy Sutton wrote:

Just concerning this PSK aspect of Sites, would this also be a similar alternative to using a shared cert (or set of certs) in tandem with the node_name_value or node_name_fact, as was recently suggested by Gary in this thread?

Yes, absolutely. However, since you're not reusing the same private key for all nodes in your deployment, Sites is a more secure approach to the problem.

[Trevor Vaughan]

I have no issue with the PSK technique BUT, I do have a couple
questions/concerns:

1) Please keep the old syntax in place so that users don't have to run
about modifying scripts everywhere. Internal command aliases should
work fine.

2) You say that we shouldn't be trusting the network (fine), but now
we're to distribute a PSK via an unsigned format (tar) over what
medium? If you don't have some sort of authenticator/identifier for
your clients, anyone on the network could make the connection and snag
the PSK, though it may be encrypted with HTTPS or somesuch.

This is (unfortunately) just a hard problem if you can't trust your
network to some degree.

Perhaps, you could bind it to the MAC address somehow? Then you only
need to worry about MAC spoofing and firewalls, etc.... Another option
would be TPM registration, but I don't know that you want to get into
all that.

What about Kerberos support? That would allow for another realm of
authentication possibilities.

Trevor

> --
> 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/-/gCtD3UXn13QJ.

>
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.



--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Jeff McCune]

On Mon, May 14, 2012 at 1:14 PM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

I have no issue with the PSK technique BUT, I do have a couple
questions/concerns:

1) Please keep the old syntax in place so that users don't have to run
about modifying scripts everywhere. Internal command aliases should
work fine.

2) You say that we shouldn't be trusting the network (fine), but now
we're to distribute a PSK via an unsigned format (tar) over what
medium? If you don't have some sort of authenticator/identifier for
your clients, anyone on the network could make the connection and snag
the PSK, though it may be encrypted with HTTPS or somesuch.

We have a number of concerns internally about literal pre-shared keys and you've identified them directly.  We think pre-shared-keys will degrade our security model of public key cryptography if used improperly.

As a result, we haven't fully scrubbed the term "PSK" from all of our notes and material on Puppet Sites but we're thinking that it might be a token or another public key itself that doesn't degrade our public key model to that of a shared secret model.

 

This is (unfortunately) just a hard problem if you can't trust your
network to some degree.

Exactly.  We're planning to address this problem with Sites by making it easier to setup Puppet in a secure way while also preserving our "secure out of the box" implementation of x.509 and trusted third party public key authentication.

 

-Jeff

[Sean Millichamp]

On Fri, 2012-05-11 at 09:39 -0700, Daniel Sauble wrote:
> Another problem is that if you move services around, you have to
> update puppet.conf on all nodes that use that service. For example, if
> you migrate your master to a new host, you have to update puppet.conf
> on every agent that uses that master. What Puppet Sites provides is a
> service registry that allows you to store this information in a
> central location. Your agents retrieve service connection information
> from the service registry. So, if your master switches to a different
> host, all you need do is update the host in the service registry, and
> all your agents will pick up that change automatically.

Daniel,

Sorry for chiming in late, but I'm just catching up on this discussion.
I didn't see explicit mention of it one way or the other, but I would
hope that whatever mechanism you are using for the service registry will
support some type of inheritance mechanism for assigning the
configuration settings at fairly arbitrary levels/grouping and not just
globally with per-host overrides.

At $WORK we are a multi-tenant environment and differing customer needs
mean that there is a potential for potentially significant Puppet
configuration variances from environment to environment. For instance,
one customer may have their own Puppetmaster environment for
catalogs/files, but share the common CA, while most other customers use
a shared set of Puppetmasters. We have created a "$customer" variable
within Puppet (available with every host) that we use with Hiera to
select out any per-customer settings. We aren't currently but may even
select Puppetmasters based on datacenter (so, $customer and $datacenter
as either/or selectors with a likely global default). Having to manage
customer-wide variances per-host would quickly get pretty unmanageable.
Right now our puppet.conf files are generated via templates (with data
pulled from Hiera) and deployed by Puppet to take into account any
variances. I like the Sites concept, but it would have to account for a
similarly high degree of flexibility to be something we'd be able to
use.

Thanks,
Sean

[Daniel Sauble]

On Friday, May 18, 2012 6:58:37 AM UTC-7, seanmil wrote:

On Fri, 2012-05-11 at 09:39 -0700, Daniel Sauble wrote:
> Another problem is that if you move services around, you have to
> update puppet.conf on all nodes that use that service. For example, if
> you migrate your master to a new host, you have to update puppet.conf
> on every agent that uses that master. What Puppet Sites provides is a
> service registry that allows you to store this information in a
> central location. Your agents retrieve service connection information
> from the service registry. So, if your master switches to a different
> host, all you need do is update the host in the service registry, and
> all your agents will pick up that change automatically.

Sorry for chiming in late, but I'm just catching up on this discussion.
I didn't see explicit mention of it one way or the other, but I would
hope that whatever mechanism you are using for the service registry will
support some type of inheritance mechanism for assigning the
configuration settings at fairly arbitrary levels/grouping and not just
globally with per-host overrides.

We've been kicking around the idea of "sites of sites", where each site could

inherit from a parent site, contain a subset of the nodes in the root site, and 

override service registry data as needed. We don't have the details hashed out 

entirely, so feedback like yours will help us converge on something useful, but 

our goal is to provide some kind of hierarchical service registry without reinventing 

Hiera.

It's a sticky problem. In order to provide a superior user experience, we decided to 

drop hierarchical sites from the initial release of Puppet Sites. So, expect 

hierarchical sites in the future, when we've had a chance to learn and iterate.

Thanks for the feedback,

- Daniel