Issue #6879 has been updated by Daniel Pittman.
Hrm. I was just reminded this existed, and re-reading it I captured the need, but didn't do a great job explaining *how* I envisioned this working. I was thinking of three large scale and successful capabilities implementations on existing protocols here: 1. SMTP capabilities in the EHLO era, onwards. 2. IMAP capabilities. 3. HTTP content and CTE negotiation. The critical feature of all of those was the use of a large, and extensible, token pool for capabilities: these were not 32 bits worth of flags, but rather a set of keywords that could be extended at any time. I think preserving that property is valuable in the final implementation. ---------------------------------------- Feature #6879: Add `capabilities` to the puppet agent / master communication. https://projects.puppetlabs.com/issues/6879#change-90114 * Author: Daniel Pittman * Status: Accepted * Priority: Normal * Assignee: eric sorenson * Category: API * Target version: 3.x * Affected Puppet version: * Keywords: backlog * Branch: ---------------------------------------- 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
