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

Change rich data in Catalog so that it becomes backward compatible


    • Type: Improvement
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 4.9.4
    • Fix Version/s: PUP 4.10.1
    • Component/s: None
    • Labels:
    • Template:
    • Team:
      Puppet Developer Experience
    • Story Points:
    • Sprint:
      PDE 2017-04-05, PDE 2017-04-19
    • Release Notes:
      Not Needed
    • QA Risk Assessment:
      No Action
    • QA Risk Assessment Reason:
      covered by unit tests; experimental


      The solution for storing rich data (AKA extended data) in the catalog that was introduced in PUP-5834 is problematic since it adds a new construct to the catalog that isn't recognized by PuppetDB. In essence, the new feature cannot be used in a PE environment until a new PuppetDB version has been released that supports this new construct.

      An interim solution, until such additions has been made to PuppetDB, would be to change the PUP-5834 implementation to instead store the rich data in normal parameters as a hash value with a magic key/value pair. The parts of the system that doesn't recognize the magic, will still be able to handle the containing resource with the limitation that it would see the hash as any other hash, instead as a rich data representation.

      In order to make the rich data somewhat eligible to use in queries, the structure of the hash will look like this (the "magic key" is the "__pcore_type__" ):

        "__pcore_type__": "SemVer",
        "value": "1.2.3-alpha"

      Complex types, (pcore Object types), must be referenced using the type name only. It is assumed that the type can be resolved by any client that needs to deserialize it.

      The current scope for the tabulation performed by the Pcore serializer, is the Catalog. This must change and instead be the Resource since it is possible to query for individual resources from PuppetDB.

      A caveat with this approach is that it will break in case someone uses the key "__pcore_type__" in a hash that is assigned to a resource parameter. The implementation should guard against this.

      As with PUP-5834. everything described here must be under the control of the rich_data setting.


          Issue Links



              • Assignee:
                thomas.hallgren Thomas Hallgren
              • Votes:
                0 Vote for this issue
                5 Start watching this issue


                • Created:

                  Zendesk Support