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

agent should support rich data content negotiation

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PUP 6.0.0
    • Component/s: None
    • Labels:
      None
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      The `rich_data` setting is now enabled by default. Catalog requests have two new content-types, `application/vnd.puppet.rich+json` and `application/vnd.puppet.rich+msgpack`, that are used when both master and agent have this enabled (and depending on whether `preferred_serialization_format` is `json` or `msgpack`).
      Show
      The `rich_data` setting is now enabled by default. Catalog requests have two new content-types, `application/vnd.puppet.rich+json` and `application/vnd.puppet.rich+msgpack`, that are used when both master and agent have this enabled (and depending on whether `preferred_serialization_format` is `json` or `msgpack`).
    • QA Risk Assessment:
      Needs Assessment

      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:

      1. (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).
      2. Raise an error and tell user to use a Binary instead of an ASCII-8bit
      3. (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

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  patrick Patrick Carlisle
                  Reporter:
                  henrik.lindberg Henrik Lindberg
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: