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

Support for autorelations of defined types inside custom types

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Normal
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Template:
    • Story Points:
      5
    • Release Notes Summary:
      The implementation of this is all on the client side (doing apply). Signing over to the client team.

      Description

      Add support for Custom types to autorelation a defined type. Currently you can only do autorelations(require, before, notify, subscribe, etc.) inside a custom type of another custom type and there is no ability to do it with a defined type.

      This feature would extend the current capability of putting the soft relationship ability of: custom type - autorequire(:customtype) do .. end, over to, custom type - autorequire(:definedtype) do .. end and if colons exist, autorequire('definedtype::define') do .. end.

      One example where this helps is with a firewall or firewalld module where you want to create a direct rule that contains an ipset, an ipset is an extension of iptables and the corresponding ipset should be created before the direct rule is created if the --match-set exists in their direct rule line. Firewall and firewalld are both custom types and ipset from mighq/ipset is currently a defined type.
      Note :component is THE wrapper class for all defined types in puppet DSL.

      Previously support for this was provided via:

        autorequire(:component) do
          ipset_arr = []
          self[:rules].each do |rule|
            if /-m\s+set.*--match-set\s+(.*?)\s+/.match(rule['args'])
              if result = catalog.resource("Ipset[#{$1}]")
                ipset_arr << result
              end
            end
          end
          ipset_arr
        end
      

      Proposed changes would allow:

        autorequire(:ipset) do
          ipset_arr = []
          self[:rules].each do |rule|
            if /-m\s+set.*--match-set\s+(.*?)\s+/.match(rule['args'])
              if result = catalog.resource("Ipset[#{$1}]")
                ipset_arr << result
              end
            end
          end
          ipset_arr
        end
      

      The only difference there is that it ensures we have a defined type of that name(:ipset) prior to going into &block to parse the details, whereas :component is the custom type wrapper class for all defined types and is rather generic which means any class that calls :component will run &block even if the defined type it's looking for isn't in the catalog. It's no real time savings and may be a slight compile burden but allows for more straightforward flexible autorelations usage. I could also just return in my ipset_arr the names of the ipset rules at that point such as $1 rather than grabbing catalog.resource("Ipset{$1}") (the whole resource) as the autorelations already knows how to handle it if we return an array in our &block that doesn't include the resource, rather only the namevar contents of the resource that we're wishing to autorelation.
      That would bring us inline with how File autorelations work where it's often

      [self[:name]]

      that's used. We can then do:

        autorequire(:ipset) do
          ipset_arr = []
          self[:rules].each do |rule|
            if /-m\s+set.*--match-set\s+(.*?)\s+/.match(rule['args'])
                ipset_arr << $1
            end
          end
          ipset_arr
        end
      

      Finally here is the link to the PR to supply this feature, I have yet to create a spec test for this but it works.
      https://github.com/puppetlabs/puppet/pull/4337

      Also defined types that are inside of modules and not root can be called via autorequire('module::definedtype') do .. end

        Attachments

          Activity

            People

            Assignee:
            asasfu Adam S
            Reporter:
            asasfu Adam S
            QA Contact:
            Eric Thompson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Zendesk Support