add possibility to manage network interfaces with a template

[trefzer]

This gives the possibility to manage all network/netdev/link settings from hashes.

I'm aware of pull request #340 from @rwaffen which started an equal solution last year.
Since the development there does not seem to go on, I started this solution which currrently
gives us the opportunitiy to create any configuration stated in the systemd documentation.

All type defintions are taken out of systemd documentation (not documented, not in our type defintion).
I'm aware, that some types could defined more accurate, but I tried to get a compromise inbetween accurate type and
workload ;).

[kenyon]

Better to put the closing braces on separate lines to avoid the need for double indentation:

Suggested change

	fname => "${_filename}.link",
	config => deep_merge(pick($link_profiles[$interface_name], {}), $interface['link']),
	}),
	fname => "${_filename}.link",
	config => deep_merge(pick($link_profiles[$interface_name], {}), $interface['link']),
	},
	),

[trefzer]

I don't think that this makes the code better readable. I will not change that for now.

[kenyon]

It does. The double indentation that you have to do currently is really just a bug in puppet-lint, I think.

[trefzer]

no the double intentation is correct since there are to brackets to intent.
to clarify:
my solution:

epp('template, {
    var => val,
})

your solution:

epp('template,
 {
    var => val,
 }
)

[kenyon]

Yes, IMO it is easier to follow the indentation when there is only at most one level of change between each line (your example has var => val, indented one level too far in my solution), easier to match up the opening and closing braces, and reduces diffs when adding and removing items to the comma-separated lists by already having separate lines.

[trefzer]

ok validatio now fails, the it needs 12 spaces, no way to lower that.
I will remove the last commit tomorrow. Think we can resolv this.

[kenyon]

Right, it's clearly not correct to have the closing brace on the same line as the content inside of the brace. You'd have to also move the opening brace and fix the indentation.

[bastelfreak]

my suggestion:

      $data = { fname  => "${_filename}.link", config => deep_merge(pick($link_profiles[$interface_name], {}), $interface['link'])}
      systemd::network { "${_filename}.link":
        path    => $path,
        content => epp('systemd/network.epp', $data),
      }

[trefzer]

@bastelfreak I am not convinced that this is a better solution. Adding additional variables does not seem to be necessary as the line for config is not too long.

In my opinion, my suggestion is still the most readable, although the double indentation created by the lint logic is kind of strange. But in the end it makes sense (the lint logic).

[tuxmea]

Personally I prefer to keep each brace in a separate line.
Yes, more lines of code, but better understanding, why indentation is needed.

$interfaces.each | String[1] $interface_name, Systemd::Interface $interface | {
  $_filename=pick($interface['filename'], $interface_name)
  if 'link' in $interface.keys() {
    systemd::network { "${_filename}.link":
      path    => $path,
      content => epp('systemd/network.epp',
        {
          fname  => "${_filename}.link",
          config => deep_merge(pick($link_profiles[$interface_name], {}), $interface['link']),
        }
      ),
    }
  }
}

[traylenator]

I've the same comment as the last one - #340 (comment)

Why a new template here.

The existing template just needs a another two lines to support each of the [Match] and [Link] sections
and new types can be added Systemd::Unit::Match and Systemd::Unit::Link

Once that is done it may make sense to create a systemd::network that uses these but if not done this way you loose all
the basics of managing a say a drop in and creating a validated file, .link files would become some special unit file and they are not.

I would say just do an equivalent MR as #502 was done for .swap units.

A .link file is just another unit file.

[traylenator]

Something like this - #513

which is a skeleton and the great work on the types here could be moved over to that structure to be consistent with the other units.

[traylenator]

Suggested change

	'Description' => Optional[String[1]],
	Optional['Description'] => String[1],

Does this stop a massive hash of unset values being added to the catalogue.

[trefzer]

Oh interesting did not realize this difference yet. Do you have more information about the difference ?

[traylenator]

I don't have a reference.

One says the key does not have to be present in the hash at all.

The other adds the key with a default value or undef.
Would have to check the catalogue to see if there is a difference.

[trefzer]

Theres no undef in the catalog either way.
Adding the following type:

type Test::Test = Struct[{
    'always'        => String[1],
    'one'           => Optional[String[1]],
    Optional['two'] => String[1],
}]

Using it in a class:
Test::Test $te = { 'always' => '2' },

Renders in the catalog to:

- type: Class
  ....
  parameters:
    te:
      always: '2'

Neither one nor two key of the hash is in the catalog.
So I assume there is no difference in the result beside the writing in the code.