FAQ
I have set up puppet to create a facts.yaml file for mcollective using the
following line:

content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s =~
/(uptime.*|timestamp|.*free|macaddress.*|ipaddress)/ }.to_yaml %>"),

However, it is creating a lot of unnecessary changes by reordering the
facts in the yaml output as you can see in the diff output between to runs;

--- facts.yaml 2012-12-03 10:25:15.389570751 +0000
+++ facts.yaml.copy 2012-12-03 10:24:31.982563969 +0000
@@ -5,14 +5,14 @@
clientcert: rhel6test.shef.ac.uk
rubyversion: "1.8.7"
lsbdistdescription: "Red Hat Enterprise Linux Server release 6.3
(Santiago)"
- architecture: x86_64
boardmanufacturer: "Intel Corporation"
+ architecture: x86_64
type: Other
serialnumber: "VMware-42 26 2c 7e 64 54 65 e5-bd 53 81 d7 56 02 2e e4"
- processorthreadcount: "1"
lsbmajdistrelease: "6"
+ processorthreadcount: "1"
title: "mcollective::server"
lsbdistcodename: Santiago
mcollective_serverpackage: mcollective
id: root


At first I was thinking of just changing the template so that the the yaml
output is sorted by key order
(http://www.dzone.com/snippets/generating-yaml-hashes-sorted) but is this
expected behaviour? Is there a better way to solve this problem?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6qtipfsFHt4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Ellison Marks at Dec 3, 2012 at 5:44 pm
    I ran into the same thing. I think whoever made the snippet on the facts
    via YAML page was either relying on some feature of a previous version of
    ruby or simply didn't think the reordering was a problem. Given that they
    included this line in their example:

    loglevel => debug, # this is needed to avoid it being logged and reported on every run


    I'm inclined toward the second option.
    On Monday, December 3, 2012 2:39:33 AM UTC-8, Andrew Beresford wrote:

    I have set up puppet to create a facts.yaml file for mcollective using the
    following line:

    content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s =~
    /(uptime.*|timestamp|.*free|macaddress.*|ipaddress)/ }.to_yaml %>"),

    However, it is creating a lot of unnecessary changes by reordering the
    facts in the yaml output as you can see in the diff output between to runs;

    --- facts.yaml 2012-12-03 10:25:15.389570751 +0000
    +++ facts.yaml.copy 2012-12-03 10:24:31.982563969 +0000
    @@ -5,14 +5,14 @@
    clientcert: rhel6test.shef.ac.uk
    rubyversion: "1.8.7"
    lsbdistdescription: "Red Hat Enterprise Linux Server release 6.3
    (Santiago)"
    - architecture: x86_64
    boardmanufacturer: "Intel Corporation"
    + architecture: x86_64
    type: Other
    serialnumber: "VMware-42 26 2c 7e 64 54 65 e5-bd 53 81 d7 56 02 2e e4"
    - processorthreadcount: "1"
    lsbmajdistrelease: "6"
    + processorthreadcount: "1"
    title: "mcollective::server"
    lsbdistcodename: Santiago
    mcollective_serverpackage: mcollective
    id: root


    At first I was thinking of just changing the template so that the the yaml
    output is sorted by key order (
    http://www.dzone.com/snippets/generating-yaml-hashes-sorted) but is this
    expected behaviour? Is there a better way to solve this problem?
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/XwLTihGzlpsJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Andrew Beresford at Dec 5, 2012 at 3:22 pm
    I've ended up separating the template into an external file and then doing
    something horrible;

    out=scope.to_hash.reject { |k,v| k.to_s =~
    /(uptime.*|timestamp|.*free|macaddress.*|ipaddress)/ }.to_yaml.split "\n"
    header = out.shift
    header = header+"\n"
    sorted = out.sort
    sorted_string = sorted.join "\n"
    header << sorted_string

    This only works because the structure of the facts.yaml content is very
    simple, and I'd much rather replace it with something more elegant.

    I was originally trying to override the Hash to_yaml method to output the
    keys in alphabetical order, but I ended up fighting with it too much and
    gave up as I had other more important stuff to work on.

    Andrew
    On Monday, 3 December 2012 17:44:08 UTC, Ellison Marks wrote:

    I ran into the same thing. I think whoever made the snippet on the facts
    via YAML page was either relying on some feature of a previous version of
    ruby or simply didn't think the reordering was a problem. Given that they
    included this line in their example:

    loglevel => debug, # this is needed to avoid it being logged and reported on every run


    I'm inclined toward the second option.
    On Monday, December 3, 2012 2:39:33 AM UTC-8, Andrew Beresford wrote:

    I have set up puppet to create a facts.yaml file for mcollective using
    the following line:

    content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s =~
    /(uptime.*|timestamp|.*free|macaddress.*|ipaddress)/ }.to_yaml %>"),

    However, it is creating a lot of unnecessary changes by reordering the
    facts in the yaml output as you can see in the diff output between to runs;

    --- facts.yaml 2012-12-03 10:25:15.389570751 +0000
    +++ facts.yaml.copy 2012-12-03 10:24:31.982563969 +0000
    @@ -5,14 +5,14 @@
    clientcert: rhel6test.shef.ac.uk
    rubyversion: "1.8.7"
    lsbdistdescription: "Red Hat Enterprise Linux Server release 6.3
    (Santiago)"
    - architecture: x86_64
    boardmanufacturer: "Intel Corporation"
    + architecture: x86_64
    type: Other
    serialnumber: "VMware-42 26 2c 7e 64 54 65 e5-bd 53 81 d7 56 02 2e e4"
    - processorthreadcount: "1"
    lsbmajdistrelease: "6"
    + processorthreadcount: "1"
    title: "mcollective::server"
    lsbdistcodename: Santiago
    mcollective_serverpackage: mcollective
    id: root


    At first I was thinking of just changing the template so that the the
    yaml output is sorted by key order (
    http://www.dzone.com/snippets/generating-yaml-hashes-sorted) but is this
    expected behaviour? Is there a better way to solve this problem?
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zDX2gss1OpYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Konrad Scherer at Dec 6, 2012 at 3:33 pm

    On 12/05/2012 10:22 AM, Andrew Beresford wrote:
    I've ended up separating the template into an external file and then doing
    something horrible;

    out=scope.to_hash.reject { |k,v| k.to_s =~
    /(uptime.*|timestamp|.*free|macaddress.*|ipaddress)/ }.to_yaml.split "\n"
    header = out.shift
    header = header+"\n"
    sorted = out.sort
    sorted_string = sorted.join "\n"
    header << sorted_string

    This only works because the structure of the facts.yaml content is very simple,
    and I'd much rather replace it with something more elegant.

    I was originally trying to override the Hash to_yaml method to output the keys
    in alphabetical order, but I ended up fighting with it too much and gave up as I
    had other more important stuff to work on.
    I had the same problem and tried an equally ugly hack which worked until the
    yaml started containing perfectly legal yaml anchors and aliases (&id001 and
    *id001)[1]. My current solution is:

    cron {
    'generate_facts':
    command => '/usr/bin/facter --puppet --yaml >
    /etc/mcollective/facter.yaml 2> /dev/null',
    minute => '0';
    }

    This does miss the puppet variables in the current scope (move to custom fact?)
    and potentially quickly changing facts (handled with facter_dot_d?). But this
    works for my needs. If anyone has a better idea I would be very interested.

    [1]: http://yaml.org/spec/1.2/spec.html#id2760395

    --
    Konrad Scherer, Sr. Engineer, Linux Products Group, Wind River
    direct 613-963-1342 fax 613-592-2283

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jakov Sosic at Dec 14, 2012 at 2:06 pm

    On 12/03/2012 11:39 AM, Andrew Beresford wrote:
    I have set up puppet to create a facts.yaml file for mcollective using
    the following line:
    There was another thread open few days ago, and suggested solution was:

    content => inline_template('<%= Hash[scope.to_hash.reject { |k,v|
    k.to_s =~ /(uptime|timestamp|memory|free|swap)/ }.sort].to_yaml %>'),


    This works for me (TM) :)

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedDec 3, '12 at 3:09p
activeDec 14, '12 at 2:06p
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase