Details
-
Improvement
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
Description
The 6.0 agent should request a catalog using a rich-data encoding by default.
The request rather than the current --rich-data setting should control the format of the catalog. (The setting is still needed but it should default to true for command line execution).
An agent < 6.0 when talking to a server >= 6.0.0 will not know how to request rich data format (now it assumes rich data if it has --rich-data turned on.
I think it is safe to assume that we can simply ignore the --rich-data flag on the agent side and state that in order to use rich-data you need to use a 6.y agent.
Further - in the current protocol, we change the encoding from JSON (the default) to PSON if we detect ASCII-8bit String data. With rich-data encoding we should not do this. There are options:
- (Magically) transform the ASCII-8bit String to a Binary - the agent will need to be able to deal with an instance of Binary (our File resource will be able to do so).
- Raise an error and tell user to use a Binary instead of an ASCII-8bit
- (Magically) deserialize a Binary to ASCII-8bit on the agent side to allow types and providers that are unaware of the Binary type work as they did before. (This has bad side effects further downstream in reports etc).
Number 2 is the preferred (non magical) solution.
Attachments
Issue Links
- is duplicated by
-
PUP-8726 Agent Functions - Content negotiation of rich data types to old/new agents
-
- Closed
-
- relates to
-
MODULES-8175 DSC_lite : MSFT_Credential validation fails with a Puppet 6 server and Puppet 5 agent
-
- Resolved
-