Mailinglist Archive: opensuse-kubic (25 mails)

< Previous Next >
[opensuse-kubic] Heads Up! Please don't let me break Factory (yet)
Hi all,

As we are moving to cri-o by default, I've just sent the following
SR's to devel:kubic (and
devel:CaaSP:Head:ControllerNode in the case of docker-kubic)

cri-o 629274
kubernetes 629273
patterns-caasp 629272
docker-kubic 629275

Feel free to review, comment, accept to devel:kubic, but do not to
Factory - I will take care of that.

I also have an open question - docker-kubic automatically resolves
these two issues with kubeadm:
[ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]:
iptables does not exist
[ERROR FileContent--proc-sys-net-ipv4-ip_forward]:
/proc/sys/net/ipv4/ip_forward contents are not set
to 1

Now I've replaced it with CRI-O people need to "modprobe br_netfilter"
and "echo '1' >

How does docker-kubic take care of that so we can consider a similar
solution over in crio kubic?

Long explanation below:
To explain why all of this has changed, I need to cover what they
collectively do (or should do - this all
worked on my machine in testing):

- Define crio as our default runtime for k8s, and now part of the
official 'container-runtime' pattern (which
also includes podman)
- Define docker as our alternative runtime, and now provided by the
official new 'alt-container-runtime'
pattern (named for both english 'alternative' and german 'alt')
- Makes kubernetes requires either runtime. Should be able to pick
what they like and we can easily make
images with either.
- Adds support to kubeadm to read a config file for easy CRI runtime
definition by users or by packages (patch
also submitted upstream)
- Adds a subpackage to both runtimes to provide the CRI config file
now used by kubeadm

These changes are dependant on the following changes to the product
configuration also

This installs both runtimes on MicroOS (for maximum exposure and
comfort for people who just want 'docker')
For kubeadm it will only install CRI-O by default

All of these changes need to be somewhat coordinated. The packages
need to land at the same time - and that
should be before/at the same time as the skelcd changes (which will be
going through the YaST CI)

And I do not want any of these changes to land before the already
submitted changes reach Factory

I want the world to enjoy nice shiny Kubic kubeadm image that works as
well as my current test system before I
risk breaking it with this plumbing

Therefore please, even if you accept the above SR's to devel:kubic,
make sure the "Forward to Factory" tickbox
is NOT selected. I'd like to decide when these changes go to Factory please

To unsubscribe, e-mail: opensuse-kubic+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kubic+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
  • No further messages