Can the order of Hash Parameters be controlled?

Support
1

Hi all,
I don't seem to recall having this little issue before I began using
Foreman, but I use a bunch of modules that have a Hash parameter called
"Options" for use mostly with the config file template. Using OpenSSH as
an example, there are a number of nice default config values in RHEL's
openssh. What we have is, by using the Options hash, allowing the admin to
adjust any parameter he/she likes. The top of the config template looks
something like:

Options managed by puppet module Options Hash…

<% options.each do |key, value| -%>
<%= key %> <%= value %>
<% end -%>

By default, the Options hash is specified at a HostGroup level within
Foreman and may be overridden by the Host's owner, or a nested HostGroup.
What I find in foreman is that whenever options has more than 2 key/val
pairs, every other puppet run flips the parsing order of the hash around
and thus rewrites the config file, and causes an activity report.

Is there a better way to do this other than doing an options hash check for
every possible parameter the config can have?

Thanks!

2

There are several ways to skin this cat. Here's one:

options.keys.sort.each do |key|
<%= key %> <%= options[key] %>
end

··· On Thu, Oct 31, 2013 at 11:42 AM, Sean Alderman wrote:

Hi all,
I don’t seem to recall having this little issue before I began using
Foreman, but I use a bunch of modules that have a Hash parameter called
"Options" for use mostly with the config file template. Using OpenSSH as
an example, there are a number of nice default config values in RHEL’s
openssh. What we have is, by using the Options hash, allowing the admin to
adjust any parameter he/she likes. The top of the config template looks
something like:

Options managed by puppet module Options Hash…

<% options.each do |key, value| -%>
<%= key %> <%= value %>
<% end -%>

By default, the Options hash is specified at a HostGroup level within
Foreman and may be overridden by the Host’s owner, or a nested HostGroup.
What I find in foreman is that whenever options has more than 2 key/val
pairs, every other puppet run flips the parsing order of the hash around
and thus rewrites the config file, and causes an activity report.

Is there a better way to do this other than doing an options hash check
for every possible parameter the config can have?

Thanks!

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.

3

Excellent. I pushed that change into our development environment last
night and we're down to one active system, which is a known issue between
my ntp module fighting against dhcp-client.

Thanks for the tip!

On a side note, is this ordering of hash params related to creating the
hash from within Foreman as opposed to inside a manifest?

··· On Thursday, October 31, 2013 2:57:08 PM UTC-4, Aaron Stone wrote: > > There are several ways to skin this cat. Here's one: > > options.keys.sort.each do |key| > <%= key %> <%= options[key] %> > end > > > On Thu, Oct 31, 2013 at 11:42 AM, Sean Alderman <salde...@udayton.edu > > wrote: > >> Hi all, >> I don't seem to recall having this little issue before I began using >> Foreman, but I use a bunch of modules that have a Hash parameter called >> "Options" for use mostly with the config file template. Using OpenSSH as >> an example, there are a number of nice default config values in RHEL's >> openssh. What we have is, by using the Options hash, allowing the admin to >> adjust any parameter he/she likes. The top of the config template looks >> something like: >> >> # Options managed by puppet module Options Hash... >> <% options.each do |key, value| -%> >> <%= key %> <%= value %> >> <% end -%> >> >> By default, the Options hash is specified at a HostGroup level within >> Foreman and may be overridden by the Host's owner, or a nested HostGroup. >> What I find in foreman is that whenever options has more than 2 key/val >> pairs, every other puppet run flips the parsing order of the hash around >> and thus rewrites the config file, and causes an activity report. >> >> Is there a better way to do this other than doing an options hash check >> for every possible parameter the config can have? >> >> Thanks! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/groups/opt_out. >> > >
4

In computer science terms, a hash data structure is not ordered. A
particular implementation, Ruby in this case, in version 1.9 and above,
chooses to enumerate hashes in the same order as the hash keys were
inserted. If you're on Ruby 1.8, hash ordering is undefined (internally I
think it's based on hash key position). And regardless, if you do not have
consistent hash insertion order (ala Puppet dependency resolution), then
consistent enumeration order won't help anyhow.

··· On Fri, Nov 1, 2013 at 7:48 AM, Sean Alderman wrote:

Excellent. I pushed that change into our development environment last
night and we’re down to one active system, which is a known issue between
my ntp module fighting against dhcp-client.

Thanks for the tip!

On a side note, is this ordering of hash params related to creating the
hash from within Foreman as opposed to inside a manifest?

On Thursday, October 31, 2013 2:57:08 PM UTC-4, Aaron Stone wrote:

There are several ways to skin this cat. Here’s one:

options.keys.sort.each do |key|
<%= key %> <%= options[key] %>
end

On Thu, Oct 31, 2013 at 11:42 AM, Sean Alderman salde...@udayton.eduwrote:

Hi all,
I don’t seem to recall having this little issue before I began using
Foreman, but I use a bunch of modules that have a Hash parameter called
"Options" for use mostly with the config file template. Using OpenSSH as
an example, there are a number of nice default config values in RHEL’s
openssh. What we have is, by using the Options hash, allowing the admin to
adjust any parameter he/she likes. The top of the config template looks
something like:

Options managed by puppet module Options Hash…

<% options.each do |key, value| -%>
<%= key %> <%= value %>
<% end -%>

By default, the Options hash is specified at a HostGroup level within
Foreman and may be overridden by the Host’s owner, or a nested HostGroup.
What I find in foreman is that whenever options has more than 2 key/val
pairs, every other puppet run flips the parsing order of the hash around
and thus rewrites the config file, and causes an activity report.

Is there a better way to do this other than doing an options hash check
for every possible parameter the config can have?

Thanks!

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user…@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.

Visit this group at http://groups.google.com/**group/foreman-usershttp://groups.google.com/group/foreman-users
.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.