tickets | 1 May 02:44 2012

[Puppet - Feature #8235] (Merged - Pending Release) There should be a plugin system for tools like hiera

Issue #8235 has been updated by Daniel Pittman.
  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

Feature #8235: There should be a plugin system for tools like hiera

  • Author: Luke Kanies
  • Status: Merged - Pending Release
  • Priority: Normal
  • Assignee: Kelsey Hightower
  • Category: parser
  • Target version: Telly
  • Affected Puppet version:
  • Keywords:
  • Branch: https://github.com/puppetlabs/puppet/pull/718

Arri’s new extlookup replacement, Hiera (https://github.com/ripienaar/hiera), is exactly the kind of system we want to add to Puppet, but we don’t want to hard-code the connection.

The connection between the tools is relatively simple – I’ve got an example in my prototype/2.7.x/hiera_integration branch and the diff for the integration is 67 lines – but the plugability really needs to be present before this is added.

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

tickets | 1 May 13:30 2012

[Facter - Feature #7559] Fact for identifying Amazon VPC instances.

Issue #7559 has been updated by Patrick Otto.

    +1 with dpittman, it looks like this needs a more general approach as this is also a problem on OpenStack. I’m not sure yet wether this can be fixed by defining the MAC address range (either in OpenStack or libvirt), but I’m looking into this (as I’m submitting a few fixes for bodepd’s openstack project).

    ubuntu <at> hello-world:~$ curl http://169.254.169.254/2008-02-01/meta-data/instance-id i-00000002 ubuntu <at> hello-world:~$ ubuntu <at> hello-world:~$ facter -d metadata Caught recursion on kernel value for kernel is still nil Not an EC2 host ubuntu <at> hello-world:~$

    Feature #7559: Fact for identifying Amazon VPC instances.

    • Author: Nigel Kersten
    • Status: Needs Decision
    • Priority: Normal
    • Assignee: Ken Barber
    • Category: library
    • Target version:
    • Keywords:
    • Branch:
    • Affected Facter version:

    (From the list)

    I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn’t work. This seems to be because VPC instances don’t use the fe:ff:ff:… MAC addresses.

    /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0

    Of the two VPC EC2 instances I’ve seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don’t know if this holds for every VPC instance, YMMV.

    in ec2.rb , the following seemed to work:

    def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end

    You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

    --
    You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
    To post to this group, send email to puppet-bugs <at> googlegroups.com.
    To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

    tickets | 1 May 15:20 2012

    [Puppet - Bug #1457] Warning about 'not loading confine' should be removed

    Issue #1457 has been updated by Spencer Krum.

      I also found this problem, and this fix works. Did you create a branch on github/pull request?

      Bug #1457: Warning about 'not loading confine' should be removed

      • Author: Digant Kasundra
      • Status: Closed
      • Priority: Normal
      • Assignee: James Turnbull
      • Category:
      • Target version: 0.24.6
      • Affected Puppet version: 0.24.5
      • Keywords:
      • Branch:

      Running puppet using the rpm'ed version of 0.24.5-1 from David Lutterkort’s yum repo generates the following errors which do not seem to affect puppet’s work but appear on each run.

      {{{ Running Puppet in one-shot mode. (may take a couple of minutes depending on number of changes) [0;34mdebug: Creating default schedules[0m Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem [0;34mdebug: Failed to load library ‘shadow’ for feature ‘libshadow’[0m [0;34mdebug: Failed to load library ‘ldap’ for feature ‘ldap’[0m Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/puppet/ssl][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/public_keys]: Autorequiring File[/var/lib/puppet/ssl][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/var/lib/puppet/ssl/certs][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/certs/brocksamson.stanford.edu.pem]: Autorequiring File[/var/lib/puppet/ssl/certs][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/puppet/ssl][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/puppet][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/private_keys/brocksamson.stanford.edu.pem]: Autorequiring File[/var/lib/puppet/ssl/private_keys][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/public_keys/brocksamson.stanford.edu.pem]: Autorequiring File[/var/lib/puppet/ssl/public_keys][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/var/lib/puppet/state][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/var/lib/puppet/ssl][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/var/lib/puppet/ssl/csr_brocksamson.stanford.edu.pem]: Autorequiring File[/var/lib/puppet/ssl][0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/var/lib/puppet/state/state.yaml]: Changing mode[0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/var/lib/puppet/state/state.yaml]: 1 change(s)[0m [0;34mdebug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/var/lib/puppet/state/state.yaml]/mode: mode changed ‘640’ to ‘660’[0m [0;34mdebug: Finishing transaction 91453739472 with 1 changes[0m [0;34mdebug: Loaded state in 0.01 seconds[0m [0;34mdebug: Puppet::Network::Client::File: defining fileserver.describe[0m [0;34mdebug: Puppet::Network::Client::File: defining fileserver.list[0m [0;34mdebug: Puppet::Network::Client::File: defining fileserver.retrieve[0m [0;32minfo: Retrieving plugins[0m [0;34mdebug: Calling fileserver.list[0m [0;34mdebug: Calling fileserver.describe[0m [0;34mdebug: Calling fileserver.list[0m [0;34mdebug: Calling fileserver.describe[0m [0;34mdebug: Calling fileserver.list[0m [0;34mdebug: Calling fileserver.describe[0m [0;34mdebug: Calling fileserver.list[0m [0;34mdebug: Calling fileserver.describe[0m [0;34mdebug: Finishing transaction 91453877912 with 0 changes[0m [0;34mdebug: Retrieved facts in 0.17 seconds[0m [0;34mdebug: Retrieving catalog[0m [0;34mdebug: Calling puppetmaster.getconfig[0m [0;34mdebug: Retrieved catalog in 3.50 seconds[0m Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem [0;34mdebug: Puppet::Type::Package::ProviderRpm: Executing ‘/bin/rpm —version’[0m Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem [0;34mdebug: Puppet::Type::Package::ProviderAptrpm: Executing ‘/bin/rpm -ql rpm’[0m [0;34mdebug: Puppet::Type::Package::ProviderYum: Executing ‘/bin/rpm —version’[0m Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem [0;34mdebug: Puppet::Type::Package::ProviderUrpmi: Executing ‘/bin/rpm -ql rpm’[0m Could not load confine test ‘operatingsystem’: No such file to load — puppet/provider/confine/operatingsystem [0;34mdebug: file /usr/sbin/update-rc.d does not exist[0m [0;34mdebug: file /sbin/rc-update does not exist[0m [0;34mdebug: file /usr/sbin/svcadm does not exist[0m [0;34mdebug: true value when expecting false[0m [0;34mdebug: file /usr/bin/dscl does not exist[0m [0;34mdebug: file nireport does not exist[0m [0;34mdebug: file pw does not exist[0m [0;32minfo: /Package[jdk]: Adding aliases “java5”[0m [0;34mdebug: Creating default schedules[0m [0;32minfo: Caching catalog at /var/lib/puppet/localconfig.yaml[0m [0;31mnotice: Starting catalog run[0m [0;34mdebug: Loaded state in 0.01 seconds[0m [0;34mdebug: true value when expecting false[0m [0;34mdebug: file /usr/bin/dscl does not exist[0m [0;34mdebug: file nireport does not exist[0m [0;34mdebug: file pw does not exist[0m [0;34mdebug: Prefetching up2date resources for package[0m [0;34mdebug: Puppet::Type::Package::ProviderUp2date: Executing ‘/bin/rpm -qa —nosignature —nodigest —qf ’%{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH} ‘’[0m [0;34mdebug: Prefetching rpm resources for package[0m [0;34mdebug: Puppet::Type::Package::ProviderRpm: Executing ‘/bin/rpm -qa —nosignature —nodigest —qf ’%{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH} ‘’[0m

      ….

      [0;32minfo: Sent transaction report in 1.10 seconds[0m [0;31mnotice: Finished catalog run in 8.88 seconds[0m }}}

      You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

      --
      You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
      To post to this group, send email to puppet-bugs <at> googlegroups.com.
      To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
      For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

      tickets | 1 May 19:05 2012

      [Puppet - Feature #11004] Solaris 11 GA & pkg

      Issue #11004 has been updated by Ben Hughes.

        Latest fails as it’s not parsing the line correctly. The latest function is fine I believe.

        The reason it exits with 4 is because it doesn’t think it’s installed, so tries to install it again.

        If Oracle ever update any packages I could actually test it though…

        Feature #11004: Solaris 11 GA & pkg

        • Author: Robert van Veelen
        • Status: Code Insufficient
        • Priority: Normal
        • Assignee:
        • Category: package
        • Target version:
        • Affected Puppet version:
        • Keywords:
        • Branch: https://github.com/puppetlabs/puppet/pull/719

        Oracle has changed the output format of pkg again for the final release of s11. The “status” field is no longer present in the output of “pkg list -H”. There is now an IFO field that has the following status flags (from the man page):

        The last column contains a set of flags that show the status of the package: o An i in the I column shows that the package is installed. o An f in the F column shows that the package is frozen. o An o in the O column shows that the package is obsolete. An r in the O column shows that the package has been renamed (a form of obsole- tion).

        Using the work done for Bug #7986 , I have tried the following with some success (though this only uses the ‘I’ column):

        You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

        --
        You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
        To post to this group, send email to puppet-bugs <at> googlegroups.com.
        To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
        For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

        tickets | 1 May 20:21 2012

        [Puppet - Feature #11004] Solaris 11 GA & pkg

        Issue #11004 has been updated by Stefan Schulte.

          Ben Hughes wrote:

          Latest fails as it’s not parsing the line correctly. The latest function is fine I believe.

          I am referring to the error message you saw

          err: /Stage[main]/Ssh/Package[network/ssh]: Could not evaluate: Could not get latest version: undefined method `parse_line' for #

          in https://github.com/puppetlabs/puppet/commit/54e5d18#L0R56 (ticket #7986) the latest method was changed to use the parse_line classmethod to reduce code duplication. But latest itself is no classmethod so it has to use self.class.parse_line not parse_line. That’s why I said the latest method is broken since #7986. The lineparsing itself which was changed to handle solaris 11 output (so pull request https://github.com/puppetlabs/puppet/pull/719) does work I guess.

          Feature #11004: Solaris 11 GA & pkg

          • Author: Robert van Veelen
          • Status: Code Insufficient
          • Priority: Normal
          • Assignee:
          • Category: package
          • Target version:
          • Affected Puppet version:
          • Keywords:
          • Branch: https://github.com/puppetlabs/puppet/pull/719

          Oracle has changed the output format of pkg again for the final release of s11. The “status” field is no longer present in the output of “pkg list -H”. There is now an IFO field that has the following status flags (from the man page):

          The last column contains a set of flags that show the status of the package: o An i in the I column shows that the package is installed. o An f in the F column shows that the package is frozen. o An o in the O column shows that the package is obsolete. An r in the O column shows that the package has been renamed (a form of obsole- tion).

          Using the work done for Bug #7986 , I have tried the following with some success (though this only uses the ‘I’ column):

          You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

          --
          You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
          To post to this group, send email to puppet-bugs <at> googlegroups.com.
          To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
          For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

          tickets | 1 May 21:48 2012

          [Puppet - Feature #14263] (Unreviewed) Support to install modules from a git repository

          Issue #14263 has been reported by Patrick Otto.

          Feature #14263: Support to install modules from a git repository

          • Author: Patrick Otto
          • Status: Unreviewed
          • Priority: Normal
          • Assignee:
          • Category: Faces
          • Target version:
          • Affected Puppet version:
          • Keywords:
          • Branch:

          I want to install modules from a git repository

          Example usage

          # HEAD out of the master branch $ puppet module install puppetlabs-apache --git=https://github.com/puppetlabs/puppetlabs-apache.git # install some <treeish> out of the repository, this should respect branches/tags $ puppet module install puppetlabs-apache --git=https://github.com/puppetlabs/puppetlabs-apache.git --version=<treeish>

          You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

          --
          You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
          To post to this group, send email to puppet-bugs <at> googlegroups.com.
          To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
          For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

          tickets | 1 May 21:50 2012

          [Puppet - Feature #14263] Support to install modules from a git repository

          Issue #14263 has been updated by Patrick Otto.

            The docs mention a “repository”, but I have to say this feature would be really helpful (especially with the provider from #11209) to install internal/customized modules on a puppet master without going through a publishing process on something like the forge.

            Feature #14263: Support to install modules from a git repository

            • Author: Patrick Otto
            • Status: Unreviewed
            • Priority: Normal
            • Assignee:
            • Category: Faces
            • Target version:
            • Affected Puppet version:
            • Keywords:
            • Branch:

            I want to install modules from a git repository

            Example usage

            # HEAD out of the master branch $ puppet module install puppetlabs-apache --git=https://github.com/puppetlabs/puppetlabs-apache.git # install some <treeish> out of the repository, this should respect branches/tags $ puppet module install puppetlabs-apache --git=https://github.com/puppetlabs/puppetlabs-apache.git --version=<treeish>

            You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

            --
            You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
            To post to this group, send email to puppet-bugs <at> googlegroups.com.
            To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
            For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

            tickets | 1 May 22:24 2012

            [Puppet - Bug #14265] (Unreviewed) yumhelper.py: yum check-config fallback if yum module is not available does not work with yum 3.2.22

            Issue #14265 has been reported by Owen Smith.

            Bug #14265: yumhelper.py: yum check-config fallback if yum module is not available does not work with yum 3.2.22

            • Author: Owen Smith
            • Status: Unreviewed
            • Priority: Low
            • Assignee:
            • Category: package
            • Target version:
            • Affected Puppet version: 2.7.6
            • Keywords: yum yumhelper.py check-config python
            • Branch:

            I’m running Puppet on RHEL5.5. My environment has a PATH set up so that the default Python in my path is not /usr/bin/python, but a newer version of Python. This new installation does not have a yum module. Til now, I haven’t been bothering to reset my PATH when running ‘puppet apply’ on my system, and for other reasons my sudoers setup passes the env through. Though idiosyncratic, this setup does give me the opportunity to test yumhelper.py’s fallback ability if it can’t find the yum module.

            Test Case

            1. Set PATH so that an installation of Python with no yum module is first on the path. Installing the latest Python 2.7 in your home directory, and putting ~/bin first on the PATH, should do it.
            2. Modify sudoers as necessary to make sure that env_reset is disabled for Puppet runs, ensuring that Puppet sees this PATH.
            3. Create a local yum repo, let’s say at /var/lib/myrepo. Drop a test RPM in there; let’s call it test-1.0-1.x86_64.rpm. Run createrepo -d /var/lib/myrepo to update it.
            4. Set up a puppet manifest something like test.pp (see attached). Run sudo puppet apply test.pp to install the package.
            5. Create a new version of the package, let’s say test-1.1-1.x86_64.rpm, and copy it to the YUM repo. Run createrepo --update -d /var/lib/myrepo to pick up the new package. Run sudo yum clear expire-cache to make sure the update will be seen right away by YUM.
            6. You could rerun sudo puppet apply test.pp at that point, and it should fail when it invokes yumhelper.py to prefetch the ‘yum’ provider. But to make the root cause clearer, let’s run yumhelper.py directly. Do sudo python /opt/puppet/lib/ruby/site_ruby/1.8/puppet/provider/package/yumhelper.py, where python resolves to your new instance of python.

            Expected Output

            The output should look something like:

            _pkg test 0 1.1 1 ia32e

            which correctly reports that the test package has been updated to 1.1-1. Your specific arch may vary depending on how you built your package. (BTW, this should be what you would see if you ran yumhelper.py with /usr/bin/python too, only in that case it would use the yum module to get this info.)

            Actual Output

            You see:

            <type 'exceptions.AttributeError'>

            Root Cause & Workaround

            Fortunately, the comments in yumhelper.py were clear enough that I know what’s wrong. The format of yum check-config, used by the fallback, has changed between the last version yumhelper.py supports (2.*) and the version of yum I’m using (3.2.22). In this version, instead of arch being in its own space-delimited field, it’s now appended to the package name, e.g. “test.ia32e”. I don’t know when exactly this change was made in the output.

            I have a workaround patch to yumhelper.py that checks the yum version using yum-version, and grabs the arch from the first space-delimited field in that case. I’ve submitted it here if anyone finds it useful, but it is most certainly not ready for integration at this point in time.

            Other workarounds, of course, are to turn on env_reset in sudoers, or otherwise run puppet apply from an environment where PATH is standard and the yum module works.

            You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

            --
            You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
            To post to this group, send email to puppet-bugs <at> googlegroups.com.
            To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
            For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

            tickets | 1 May 22:26 2012

            [Puppet - Bug #14265] yumhelper.py: yum check-config fallback if yum module is not available does not work with yum 3.2.22

            Issue #14265 has been updated by Owen Smith.

              Update to test case step 5: should be yum clean, not yum clear.

              Bug #14265: yumhelper.py: yum check-config fallback if yum module is not available does not work with yum 3.2.22

              • Author: Owen Smith
              • Status: Unreviewed
              • Priority: Low
              • Assignee:
              • Category: package
              • Target version:
              • Affected Puppet version: 2.7.6
              • Keywords: yum yumhelper.py check-config python
              • Branch:

              I’m running Puppet on RHEL5.5. My environment has a PATH set up so that the default Python in my path is not /usr/bin/python, but a newer version of Python. This new installation does not have a yum module. Til now, I haven’t been bothering to reset my PATH when running ‘puppet apply’ on my system, and for other reasons my sudoers setup passes the env through. Though idiosyncratic, this setup does give me the opportunity to test yumhelper.py’s fallback ability if it can’t find the yum module.

              Test Case

              1. Set PATH so that an installation of Python with no yum module is first on the path. Installing the latest Python 2.7 in your home directory, and putting ~/bin first on the PATH, should do it.
              2. Modify sudoers as necessary to make sure that env_reset is disabled for Puppet runs, ensuring that Puppet sees this PATH.
              3. Create a local yum repo, let’s say at /var/lib/myrepo. Drop a test RPM in there; let’s call it test-1.0-1.x86_64.rpm. Run createrepo -d /var/lib/myrepo to update it.
              4. Set up a puppet manifest something like test.pp (see attached). Run sudo puppet apply test.pp to install the package.
              5. Create a new version of the package, let’s say test-1.1-1.x86_64.rpm, and copy it to the YUM repo. Run createrepo --update -d /var/lib/myrepo to pick up the new package. Run sudo yum clear expire-cache to make sure the update will be seen right away by YUM.
              6. You could rerun sudo puppet apply test.pp at that point, and it should fail when it invokes yumhelper.py to prefetch the ‘yum’ provider. But to make the root cause clearer, let’s run yumhelper.py directly. Do sudo python /opt/puppet/lib/ruby/site_ruby/1.8/puppet/provider/package/yumhelper.py, where python resolves to your new instance of python.

              Expected Output

              The output should look something like:

              _pkg test 0 1.1 1 ia32e

              which correctly reports that the test package has been updated to 1.1-1. Your specific arch may vary depending on how you built your package. (BTW, this should be what you would see if you ran yumhelper.py with /usr/bin/python too, only in that case it would use the yum module to get this info.)

              Actual Output

              You see:

              <type 'exceptions.AttributeError'>

              Root Cause & Workaround

              Fortunately, the comments in yumhelper.py were clear enough that I know what’s wrong. The format of yum check-config, used by the fallback, has changed between the last version yumhelper.py supports (2.*) and the version of yum I’m using (3.2.22). In this version, instead of arch being in its own space-delimited field, it’s now appended to the package name, e.g. “test.ia32e”. I don’t know when exactly this change was made in the output.

              I have a workaround patch to yumhelper.py that checks the yum version using yum-version, and grabs the arch from the first space-delimited field in that case. I’ve submitted it here if anyone finds it useful, but it is most certainly not ready for integration at this point in time.

              Other workarounds, of course, are to turn on env_reset in sudoers, or otherwise run puppet apply from an environment where PATH is standard and the yum module works.

              You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

              --
              You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
              To post to this group, send email to puppet-bugs <at> googlegroups.com.
              To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
              For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

              tickets | 1 May 23:32 2012

              [Puppet - Feature #11608] Lowrider: Data/Model separation by including Hiera-like functionality in Puppet

              Issue #11608 has been updated by Nigel Kersten.
              • Assignee changed from Nigel Kersten to Kelsey Hightower

              As discussed Kelsey, it would be great if you could update this with the plan you’re working to from the other docs.

              Feature #11608: Lowrider: Data/Model separation by including Hiera-like functionality in Puppet

              • Author: Nigel Kersten
              • Status: Needs More Information
              • Priority: Normal
              • Assignee: Kelsey Hightower
              • Category:
              • Target version:
              • Affected Puppet version:
              • Keywords:
              • Branch: https://github.com/kelseyhightower/puppet/tree/ticket/master/11608_data_separation_with_hiera

              Codename: Lowrider

              Problem

              In order for modules to be truly reusuable, you need to be able to supply site-specific data outside the module itself.

              Authors however need to be able to supply data themselves with modules, but well separated outside the manifests so that users can override data.

              Overview

              We’re going to build Hiera-like functionality into Puppet itself as a first class citizen, using the Hiera code base as a starting point, and freezing the existing Hiera project with minimal maintenance by Puppet Labs.

              “hiera” will generally be retired as a user facing element with the noun “data” and the verb “lookup”.

              Backwards compatibility will be provided by existing Hiera installs, so it’s critical that users can continue to run Hiera alongside Territory while they do any necessary migration. Existing Hiera users are important to us.

              At this stage we are looking to support a single on-disk data format, JSON.

              Goals

              1. Automatically look up unspecified class parameters in the data store.
              2. Allow manual look up of data in the data store by explicit keys.
              3. Provide a Face to interact with the data store.

              Out of scope, to implement later

              1. A remote read/write API/service wrapped around Hiera.

              Out of scope, no plan to implement later.

              1. Allow module authors to ship data in their modules.

              We have a general principle we’re looking to promote where class parameters are considered your interface for the user of your module. Just like you wouldn’t make GUI elements that control aspects of a program your users shouldn’t need to modify, you shouldn’t make class parameters for everything. This should be kept in mind with the design.

              We are not interacting with an external Hiera install here, we are creating Hiera-like functionality in Puppet core, using the Hiera code base.

              Automatically look up unspecified class parameters in the data store

              class ntp($servers=['time.puppetlabs.com']) { ... }

              Lookup Order

              1. Directly specified value
                • class { ntp: servers => ["ntp.puppetlabs.lan", "ntp2.puppetlabs.lan"] }
              2. Value via Hiera when not directly specified
                • class { ntp: } will lookup the key ntp::servers
              3. Default value in class definition when not directly specified or found in Hiera
                • class { ntp:} and class ntp ($servers=["default.server"]) { ... }

              Note the change from existing Hiera where we are now going to be looking up the fully qualified variable name as the key, avoiding the existing problem of a global namespace being polluted with ‘ntp_ntpservers’.

              Default Hierarchy

              Proposed:

              :hierarchy: - %{certname} - %{environment} - global

              Note the rename of ‘common’ in Hiera terminology to ‘global’, and associated design question.

              Allow manual look up of data in the data store by explicit keys

              Puppet manifests should have access to the data store using a data lookup function like this:

              class site { class { 'ntp': ntpservers => lookup('dmz_ntpservers'), } $maintenance_message = lookup('dmz_maintenance_state_text') file { '/etc/motd': content => $maintenance_message, } }

              This is where users can lookup arbitrary keys and use the returned data in class or resource declarations, or really for any DSL purpose.

              Puppet Data Face:

              The current Hiera CLI functionality will be ported to a Face with the following feature set:

              • Ability to read data from the data store
              • Ability to query values based on a user supplied scope

              Example:

              # Query the data backend for var_name: $ puppet data search var_name # Query the data backend for var_name with a specific scope: $ puppet data search var_name --scope "key=value"

              Puppet Deprecations

              • extlookup function

              Hiera functionality that will not survive the transition

              • “puppet” backend for Hiera
              • YAML support
              • We won’t port hiera_include() as we’re going to fix #7801

              Rough User Stories/Desires

              • As a user, I want to be able to migrate a node from prod –> test –> prod without needing to copy all the data back and forth.
                • This is the driver behind having the environment in the default hierarchy, rather than environment-specific data stores.

              Outstanding Questions

              General

              • ???
              • ???

              Design

              • Is our default hierarchy right?
              • Is ‘global’ the right name for the previously-known-as ‘common’ hierarchical layer?
              • What do we name the function(s) for data lookup? Is lookup() right?
              • With regard to the replacement of hiera_include(), do we need to enforce a convention here around the key lookup?
              • What do we do about the existing hiera config file? That can’t be expressed in puppet.conf can it?

              You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

              --
              You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
              To post to this group, send email to puppet-bugs <at> googlegroups.com.
              To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
              For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.


              Gmane