Re: [meta-virtualization][PATCH] Adding k3s recipe

["Bruce Ashfield" <bruce.ashfield@gmail.com>]

On Fri, Sep 25, 2020 at 2:20 AM Joakim Roubert <joakim.roubert@axis.com> wrote:
>
> On 2020-09-24 17:41, Bruce Ashfield wrote:
> >
> > There are at least two utilities that are shared with the main
> > kubernetes and not in our existing layer dependencies. We shouldn't
> > expand our dependencies more, so we have to look at importing a
> > variant of the recipes to meta-virt, or seeing about getting the
> > recipes into a more common location. In particular, I'm talking
> > about ipset and and upx, and I'm still looking for more.
>
> Ah, yes.
>
> > As for the service files, the k3s.service is different from the one
> > from the latest on the k3s 1.18 branch, and there's a patch that
> > modifies it. Although tempting to not use /usr/local/bin, for
> > maintenance, we'd be better off either just installing where things
> > are expected. Was something broken if /usr/local/bin was used ?
>
> The target systems I work on prohibits installations to /usr/local, so
> from my perspective something would in fact be broken if /usr/local/bin
> was to be used. Nevertheless, configuring the recipe to have
> /usr/{$VARIABLE}/bin and VARIABLE set to "local" as default would
> perhaps be an option for everybody to eat the cake and still have it?

Absolutely. I'm always in favour of making these configurable, so we
can let users customize as they see fit.

Alternatively, rather than substituting just the 'local', the path up to
'bin' could be controlled.  And by that, I mean a variable local to the
recipe, like you have above.

That allows the use of $bindir by default, and also covers the case
automatically where someone has changed $bindir to /usr/local/bin.

The local variable allows yet another override if the global $bindir
hasn't been changed, and you just want to modify it for this recipe
(which is actually what I think will be most common).

>
> > The other .service files, we have no idea where they come from by
> > looking at the series, and as such they need some sort of comment
> > (by looking at the repo, you can tell they are variants of the
> > k3s.service file, but that needs to be clarified).
>
> I will investigate.
>
> > The patches themselves to the code base (not just the overall git
> > commit) should have Signed-off-by: and Upstream-status: flags, so
> > they can be maintained as I bump through releases.
>
> I will see to that.
>
> > The scripts being created by the recipe, need license headers and
> > spdx tags. Boring, but it is something we want to make sure is in
> > new files.
>
> Absolutely!

I just had to go through the License / SPDX header addition for
hundreds of files. So I know what a pain this can be, so thanks!

>
> > Also, at a glance, we need to make sure the dependencies of the
> > scripts are captured in the DEPENDS of the recipe (i.e. I see 'ip'
> > being called, make sure that is captured).
>
> Ah, yes, I will go through that.
>
> > As for the networking, what we have in the submission is specific to
> > a setup, that's the parts that I'm really trying to unify. We need
> > to document what is expected in the CNI configuration, and then
> > control it via a distro/image flag such that it won't
> > clobber/conflict with other CNI users. I can take care of that distro
> > part, but the documentation would be ideal in a README that comes
> > along with the recipe.
>
> That also sounds like a good plan. I am not relly sure what text to
> write in that README file, though. But I guess that is something that
> can be iteratively created.

Absolutely. Just a stream of thoughts is fine for now, with a quick
overview, and perhaps a guideline on how to build a single node
system ? With a few notes about what is configured out of the box
and what we expect the end user to continue to configure / customize ?

That would be more than enough as a start.

Bruce

>
> > As I said, I'm still working through some of the factoring out and
> > de-duplication, but there's some things in there that are best done
> > on your end, versus mine.
>
> Excellent!
>
> BR,
>
> /Joakim



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II