add features

[rwaffen]

I hope this I not to much. what do you think about it?

• I wanted to have a simple working network thats why I added the simple_cni class to have a bridged network to start with. Then I went on and tried to install cilium, but this is in a early state.
• I added crictl to debug containers on notes. so I can do crictl ps and stuff. In the past we did this with docker, but we don't have docker now anymore.
• I added containerd because I wanted to use this as cri implementation.
• I moved cni_plugins into an own class
• I moved the cri section from the main class into an own module

[ananace]

I've got to do some more digging in various documentation, but I have some questions so far.

I'm still unsure about if the module should even attempt to manage more complex solutions - the resources that it currently offers for networking and the like are mainly there for solving the MVP part, with more complex choices (like cilium, calico, kube-router, linkerd, etc) being up to the admin to manage.

[rwaffen]

@SimonHoenscheid @ananace

how do we proceed here? should i remove cilium for the moment? i really would need that containerd part atm. (i'm using my fork right now, but would like to have it upstream :) )

[ananace]

My personal feeling is that offering more network implementation isn't necessarily a bad thing, but using a tool to 'install' them into the cluster as a non-idempotent exec could lead to far too many issues far too easily.
Might be better to split out the cilium pieces into a separate PR for now, it's definitely the component that's going to require the most design/thought.

[ananace]

Got another couple of nitpicks about ensure not being used properly all the way, but nothing that should stop this PR from being merged.

[rwaffen]

then lets talk. i myself are not sure what to do with the ensure. sometimes its on $ensure, but i also saw here and in other modules that it is now better to use something like stdlib::ensure($ensure, 'package'),?

what your opinion on that?

[ananace]

@rwaffen The stdlib::ensure function exists in order to support mapping the regular ensure values (absent/present) into type-specific ones (absent/ìnstalled for packages, stopped/running for services, absent/link for symlink files, etc)

If the type uses a regular absent/present, then passing $ensure directly is the best thing to do, but for specialized types like packages/services/files/directories/links/etc then using stdlib::ensure is the correct thing to do.

In the case of this PR I mainly meant that there are classes where $ensure is a parameter, but it's only applied to some of the resources. k8s::install::cni_plugins for example, where it's only applied onto the archive resource.
Amusingly enough, I find myself actually more okay with e.g. k8s::install::container_runtime in this nitpick, since there's no ensure at all on it.

Regardless, it's a nitpick that shouldn't block the PR further since the module itself isn't doing it right across the line either.

[rwaffen]

okay, now i understand. 😄