merge hashes and create_resources

[Robert Poulson]

Dear List,

I've been using Puppet for over a year now and I'm quite enjoying it. I've learned some stuff but there is of course always room for improvement. Now I have a task which needs a nicer solution than I'm currently capable of.

I have a hash of items with to key/value pairs, which is *the same for every node*:

$input_base => {
  input1 => { 'port' => '2001', 'component' => 'component1' },
  input2 => { 'port' => '2002', 'component' => 'component2' }
}

Then I have a second hash, which is different for every node.

$input_node => {
  input3 => { 'port' => '2003', 'component' => 'component3' },

  [possibly input4... inputN]

}

These all will be used in a single template. So I can simply do:

$input_merged = merge($input_base, $input_node)

The corresponding port/component entries will then be added in a configuration file with an $input_merged.each_pair - so far so good.

Now the actual task: I need an extra configfile, generated from a template, for all the inputN elements of the $input_node - but only for them, not for the $input_base elements - like this:

* /path/to/project_input3.conf

* [/path/to/project_input4.conf...project_inputN.conf]

This would be possible with create_resources:

create_resources(file, $input_merged)

but in order to do this, $input_merged should have the values of a file resource - at least "path" and "source => template()". This is not the case.

I could define $input_node initially as a file resource hash - but in this case I can't merge it anymore with $input_base.

Currently I have no other idea than manually map the input_node elements into a third hash, and use that with create_resources, but there should be a nicer solution. Do you have an idea? :-)

Best,

Rp

[Henrik Lindberg]

If you are using 3.x with future parser, or if you are on 4.x it may be
easier to use iteration over the hash(es).

$input_merged.each |$input, $options| {
file { "/path/to/project_${input}.conf":
source => template(),
# etc...
}
}

- henrik


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Luke Bigum]

In Puppet 3.x you have to use the Define Wrapper "trick". It's not pretty, but without lambda functions it's all that you've got. If it's 4.x, see Henrik's post before.

$input_base => {
input1 => { 'port' => '2001', 'component' => 'component1' },
input2 => { 'port' => '2002', 'component' => 'component2' }
}

$input_node => {
input3 => { 'port' => '2003', 'component' => 'component3' },
[possibly input4... inputN]
}

$input_merged = merge($input_base, $input_node)
file { 'input_merged_file':
content => template("template_that_uses_input_merged")
}

#Uses $port and $component params in individual File resources
define input_node_wrapper ($port, $component) {
file { "a_file_for_input_node_${name}":
path => 'somewhere',
content => 'some_other_template',
}
}
create_resources('input_node_wrapper', $input_merged)



--
Luke Bigum
Senior Systems Engineer

Information Systems

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CANwwCtzSGFSUaJsraux2sAifauq%3D9%2BHuZT-kt6jpUBJWnvVZ%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

Recognised by the most prestigious business and technology awards

2016 Best Trading & Execution, HFM US Technology Awards
2016, 2015, 2014, 2013 Best FX Trading Venue - ECN/MTF, WSL Institutional Trading Awards

2015 Winner, Deloitte UK Technology Fast 50
2015, 2014, 2013, One of the UK's fastest growing technology firms, The Sunday Times Tech Track 100
2015 Winner, Deloitte EMEA Technology Fast 500
2015, 2014, 2013 Best Margin Sector Platform, Profit & Loss Readers' Choice Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). This message is not intended for any recipient(s) who based on their nationality, place of business, domicile or for any other reason, is/are subject to local laws or regulations which prohibit the provision of such products and services. This message is subject to the following terms (http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, please notify us by replying to this email and we will send you the terms. If you are not the intended recipient, please notify the sender immediately and delete any copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a multilateral trading facility. LMAX Limited is authorised and regulated by the Financial Conduct Authority (firm registration number 509778) and is a company registered in England and Wales (number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong Kong is licensed by the Securities and Futures Commission in Hong Kong to conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE Number BDV088.

[Robert Poulson]

Dear Henrik,
dear Luke,

thank you to both of you!

I use 4.x but like the second solution too. Went with the first one tho.

Since then I realised that I'm actually using hashes of hashes... so hashes more like in a dictionary way. So the following:

$input_base => {
  input1 => { 'port' => '2001', 'component' => 'component1' },

}

with this:

$input_merged.each |$input, $options| {
  file { "/path/to/project_${input}.conf":

  ... }

would yield filenames like "/path/to/project_{ 'port' => '2001', 'component' => 'component1' }.conf" since that is the value of that key:value pair!

And iterating through this key:value pair (in a nested .each) is not easy either, because for the .each function, the key is once "port" and value is "2001", then the key will be "component" and the value will be "component1". So I'd have two configfiles for every inputN.

I simplified the the input format to:

$input_base => {

  '2001' => 'component1',
  '2002 => 'component2',

}

and now I can simply iterate them over with a single .each.

I'm clearly missing the developer mindset (yet... I hope) and have to learn some basics as well for every task I solve.

Thank you,

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/754207562.4617421.1465201278090.JavaMail.zimbra%40lmax.com.

[Henrik Lindberg]

On 06/06/16 15:52, Robert Poulson wrote:
> Dear Henrik,
> dear Luke,
>
> thank you to both of you!
>
> I use 4.x but like the second solution too. Went with the first one tho.
>
> Since then I realised that I'm actually using hashes of hashes... so
> hashes more like in a dictionary way. So the following:
>
> $input_base => {
> input1 => { 'port' => '2001', 'component' => 'component1' },
> }
>
> with this:
>
> $input_merged.each |$input, $options| {
> file { "/path/to/project_${input}.conf":
> ... }
>
> would yield filenames like "/path/to/project_{ 'port' => '2001',
> 'component' => 'component1' }.conf" since that is the value of that
> key:value pair!
>
> And iterating through this key:value pair (in a nested .each) is not
> easy either, because for the .each function, the key is once "port" and
> value is "2001", then the key will be "component" and the value will be
> "component1". So I'd have two configfiles for every inputN.
>

You could have accessed $input[port] and $input[component] in your path
(title), and where you needed those values). You changed data structure
is probably better (and ok) since port is probably unique anyway so you
don't need the extra indirection of naming the inputs.

- henrik