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

agent should support rich data content negotiation

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • None
    • PUP 6.0.0
    • None
    • None
    • New Feature
    • 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`).
    • 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

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Zendesk Support