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.

[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']),
        }
      ),
    }
  }
}

[jay7x]

IIRC, it's possible to omit curly brackets if last argument of a function is a Hash.. so can drop pair of brackets from epp() call.

[trefzer]

I think we should close this discussion. To conclude:
There are several ways to indent with many newlines or less newlines. The choosen variant (like other proposed variants) is/are accepted by the puppet linter. If this or another variant is not acceptable I think we should change the linter and discuss the issue there !

[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]

@trefzer are you happy if #513 is merged and then you can other unit types be added in the same way? To be consistent with the other units.

[trefzer]

Well I just had a short look at the template (unit_file.epp) you mentioned. If I got that right, I need to add all possible sections (~50 entries for network file, ~28 entries for netdev file and 4 for link file) into the $_unit_sections variable and as a parameter of the template. This means we will have approximatly 80 parameters for the template ! a no go. I did even not look at the parameter $_tupled_values where we probably also need to add douzens of entries.

I agree, that the idea of having one template for all unit files is not a bad idea. But then we should think the other way round. Taking my network.pp file and use it as a general unit file.
The network.epp is prepared to be a generic unit file. It only requires proper definition of the types used.

So to conclude will not adapt this PR to use the unit_file.epp template.

I'm a bit sorry for this answer, but I think having the definition of what a section and a tupled value is belongs into the type definition and not in a template.

[trefzer]

@traylenator @bastelfreak well #513 seems already be merged.

If you want to really go the way with the unit_file.epp template, I can remove my template and the manifest using it (so only keep the types).
But then it's up to you to adapt the unit_file.epp template accordingly.

[traylenator]

I should have marked #513 as a draft while it was still a question, comment on this review.

I looked at the .link and .match man pages but not the .netdev where indeed the number of possible sections explodes.

[trefzer]

@traylenator no problem. So we close this discussion ?

[traylenator]

I still think its worth striving to reuse the existing manage_unit , manage_dropin and template if we can.

The current manage_unit is defined as :

define systemd::manage_unit (
  Enum['present', 'absent']                $ensure                  = 'present',
  ....
  Optional[Systemd::Unit::Install]         $install_entry           = undef,
  Optional[Systemd::Unit::Unit]            $unit_entry              = undef,

Changing these options is going to be hard for everyone but how is adding a new parameter that supports,
link, match and netdev units ?

Does this work? So add a new parameter $network to systemd::manage_unit.

  Optional [Struct[{ 
      'link'  =>  Optional[Systemd::Interface::Link],
      'match =>  Optional[Systemd::Interface::Match],
      'netdev => Optional[Systemd::Interface::Netdev],
   ]
}                                                            $network_entries    = undef,

• Variable name $network_entry or $networkor even$entriesand make it fully generic. If a generic variable, e.g$entriesshould probably make a difference namespace for whole unit types Systemd::File:Link` or something.
• Obviously would have to extend the existing template but that probably doable.
• We already have iterators around systemd::manage_unit that would work straight away for generating them with hiera.
• If generic could in principle deprecate install_entry, unit_entry, ... but that would be for another possibly never happening day.

( We probably named Systemd::Unit::Install and similar wrong and it should have been `Systemd::Section::Install)

I'm probably missing something.

[trefzer]

I do not think, that this will be a good idea:

• a unit file is the configuration of init processes, the network|netdev|link configuration configures one specific unit (systemd-networkd) there are other systemd units like journal/timesyncd/resolved etc. which run as a separate unit with a separate configuration file.
• there is no need to change anything in manage_dropin since network,link and netdev files cannot act as dropins. (thats one of the main reasons to revert Add support for .link units and dropins #513)
• manage_unit is for unit files. Logically a unit file in systemd is not a network configuration, it makes sence to have a different defines for units and for network.
• if you indeed want to use the same define, then you either need to change $systemd::manage_unit::path for network definitions or implement a overwritable logic to define where the file should be written (network/link/netdev files go to /etc/systemd/network and not /etc/systemd/system
• same for enable, active, restart... since network|netdev|link is not a unit
• using systemd::networkd for the network configuration ensures that systemd--networkd is reloaded
• with the implementation of this request, I think we can deprecate the define systemd::network (without d !)

I conclude, configuring units|resolved|timesyncd etc and network with a separate puppet define and a template belonging to one define is easy to support and the code is not too complicated. And yes it could be that there is some duplicate code (but I do not think that its so much).

Or let me say: We should keep going with the Unix philosophy (although it's systemd (I couldn't resist ;))):

The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. wikipedia