Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-1443

Add `capabilities` to the puppet agent / master communication.



    • Type: New Feature
    • Status: Closed
    • Priority: Normal
    • Resolution: Won't Do
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Template:
    • Team:


      At the moment we have an assumed link between the version of the puppet agent connecting to a master, and the capabilities of that agent. We don't take a great deal of advantage of that right now, but we are starting to push into spaces were that is valuable.

      We are also aggressively pushing down the path of adding extra features as modules, where the client can gain extra capabilities by dropping in a bit of extra code, no change to the version number required.

      This implies that the current loose mapping of capabilities to version is going to get weaker as time goes on; we should resolve that by adding capabilities to the communication, and so allow the master to make correct decisions (eg: reject a client without a capability, enable a feature for a capability, or downgrade the response when a capability is missing.)

      I would propose that this be implemented as an additional client-side fact containing an array of capability flags. The agent can supply this in the normal way, and the master can use that as part of compilation, etc, to determine the right content to send.

      This gives us active negotiation over versions and capabilities in a finer-grained way than we have right now, giving us the ability to innovate faster without losing older clients along the way. It also makes it easier for our clients to audit which nodes can do what on their infrastructure.




            eric.sorenson Eric Sorenson
            redmine.exporter redmine.exporter
            0 Vote for this issue
            6 Start watching this issue



                Zendesk Support