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

Hiera 5 "uris" hierarchy parameter inappropriately type-checked

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PUP 4.10.10, PUP 5.3.4, PUP 5.4.0
    • Component/s: None
    • Labels:
      None
    • Template:
    • Team:
      Platform Core
    • Sprint:
      Platform Core KANBAN
    • Method Found:
      Needs Assessment
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      The validation of uri/uris in a hiera 5 hiera.yaml was too strict and did not allow reference / partial URIs to be used (for example only containing a path).
    • QA Risk Assessment:
      No Action

      Description

      The documentation for configuring a Hiera 5 hierarchy level can be found here. In these docs, the uris key is described as appropriate for "[...] any kind of data source. Hiera doesn’t ensure URIs are resolvable before calling the backend, and doesn’t need to understand any given URI schema."

      However, in implementation the uris key is not implemented this way, and seems to require that values match a preconception of what a URI is.

      ---
      version: 5
       
      defaults:
        datadir: "data"
       
      hierarchy:
        - name: 'Consul backend'
          lookup_key: consul_lookup_key
          uris:
            - "/v1/kv/configuration/%{fqdn}"
            - "/v1/kv/configuration/common"
      

      [cloud-user@master-of-puppets-aws-1 work]$ puppet lookup --hiera_config=hiera.yaml --modulepath=modules test --explain
      Error: Could not run: Lookup of key 'lookup_options' failed: The Lookup Configuration at '/home/cloud-user/work/hiera.yaml' has wrong type, entry 'hierarchy' index 0 entry 'uri' exp
      ects a match for Pcore::URI = Pattern[/(?x-mi:
              ([a-zA-Z][\-+.a-zA-Z\d]*):                           (?# 1: scheme)
              (?:
                 ((?:[\-_.!~*'()a-zA-Z\d;?:@&=+$,]|%[a-fA-F\d]{2})(?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*)                    (?# 2: opaque)
              |
                 (?:(?:
                   \/\/(?:
                       (?:(?:((?:[\-_.!~*'()a-zA-Z\d;:&=+$,]|%[a-fA-F\d]{2})*)@)?        (?# 3: userinfo)
                         (?:((?:(?:[a-zA-Z0-9\-.]|%\h\h)+|\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}|\[(?:(?:[a-fA-F\d]{1,4}:)*(?:[a-fA-F\d]{1,4}|\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})|(?:(?:[a-fA-F\d]{1,4}:)*[a-fA-F\d]{1,4})?::(?:(?:[a-fA-F\d]{1,4}:)*(?:[a-fA-F\d]{1,4}|\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}))?)\]))(?::(\d*))?))? (?# 4: host, 5: port)
                     |
                       ((?:[\-_.!~*'()a-zA-Z\d$,;:@&=+]|%[a-fA-F\d]{2})+)                 (?# 6: registry)
                     )
                   |
                   (?!\/\/))                           (?# XXX: '\/\/' is the mark for hostport)
                   (\/(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*(?:;(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*)*(?:\/(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*(?:;(?:[\-_.!~*'()a-zA-Z\d:@&=+$,]|%[a-fA-F\d]{2})*)*)*)?                    (?# 7: path)
                 )(?:\?((?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*))?                 (?# 8: query)
              )
              (?:\#((?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*))?                  (?# 9: fragment)
            )/], got '/v1/kv/configuration/common'
      

      As a custom backend author, I read the documentation for uris as a standardized key that I can use to specify "levels" for my backend, where the format and validation of strings representing levels is left to me. However, the implementation prevents this.

      There should be a standard key that can be used to describe levels, for which format and validation of entries is left to the backend. If uris is already this key, the undocumented type checking is a bug that needs to be removed before it can be effectively used.

        Attachments

          Activity

            jsd-sla-details-panel

              People

              • Assignee:
                Unassigned
                Reporter:
                reid Reid Vandewiele
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support