[RA2] OS Modularity requirements and features

[tomkivlin]

Suggested "minimum requirements":

• kernel version
• C library and version (glibc / musl c)
• Core utilities? (GNU Core Utils?)

[tomkivlin]

@peterwoerndle - I was talking to another vendor about this today (BSS space) and thought I'd start jotting ideas down in an Issue.

[peterwoerndle]

When you're referring to "minimum requirements", we should differentiate between Host OS and base OS, or? I assume some requirements would have to be matched, others would only apply to one or the other.

I remember that for the host OS a minimal set of kernel modules to be available have been mentioned but not further defined.

[peterwoerndle]

@tomkivlin should I just start a PR so we have some concrete text proposal to discuss. In the Prague meeting we've been in agreement to document the OS modularity. The details on "minimum requirements" we can then add iteratively.

[tomkivlin]

@peterwoerndle yes, I think some text in Chapter 04 would be useful to then start the discussion, unless you were thinking somewhere else?

[peterwoerndle]

Yes, Ch04 sounds the right place to document this. I'll create a PR asap.

[tomkivlin]

@peterwoerndle did you create a PR for this? Nothing is coming up as being linked to this. Let me know if you need me to take it on instead.

[jnummelin]

As a newbie in CNTT space, maybe a stupid question. :) Why would we want/need to pin down ANY requirements on kernel/OS/C lib level? I know k8s itself imposes some minimum requirements, but those should be implied as-is on CNTT too as we're basing RA2 anyway on k8s.

[tomkivlin]

As a newbie in CNTT space, maybe a stupid question. :) Why would we want/need to pin down ANY requirements on kernel/OS/C lib level? I know k8s itself imposes some minimum requirements, but those should be implied as-is on CNTT too as we're basing RA2 anyway on k8s.

We may have worded badly so far, but the intent of this is to increase the modularity between the Container Host OS and the Container Base Image. Today, many OS vendors will specify a need for tight coupling between the two, essentially removing much of the stated benefits of Kubernetes from a portability and abstraction point of view. i.e. if you're using Linux distro A on the Container Host OS, you must use Linux distro A's base image within the containers too.

The purpose of this issue and the PR @peterwoerndle will look to create is to clarify what are the real, functional, dependencies between the two (noting that, there will be valid non-functional reasons for OS vendors to add more, such as vendor-specific features or simply a premium level of support).

For example we might say that for any Container Host OS that uses glibc, any Container Base Image that uses the same version of glibc is conforming with the RA2 "compatibility matrix" whereas if someone came along with containers using musl - e.g. Alpine - then that does not conform.

Hope that makes sense.

[jnummelin]

i.e. if you're using Linux distro A on the Container Host OS, you must use Linux distro A's base image within the containers too.

Just out of pure curiosity, would you know any sources for these statements on any OS vendor docs? For me these make very little sense and as you said, kinda breaks the whole purpose of containers.

For example we might say that for any Container Host OS that uses glibc, any Container Base Image that uses the same version of glibc is conforming with the RA2 "compatibility matrix" whereas if someone came along with containers using musl - e.g. Alpine - then that does not conform.

I've been using glibc and musl based containers on same glibc based hosts for years with very little issues. I know there are some "corner cases" where things might not work 100% interchangeably, but making a blanked statement that you must have same implementation on both sides sounds just wrong.

As I mentioned in the call last week, I'm not against on this kind of compatibility matrix in general, I just think we need to make it based on technical reasons based on real facts if we know some components and/or requirements impose hard requirements on this level. Currently I personally have not identified any such requirements.

[CsatariGergely]

RM2 meeting on 2020.03.19 agreed to add a statement that the infrastructure should not require any specific OS in the container base image

[tomkivlin]

New issue for those mentioned in #1380 to be raised by @peterwoerndle. Closing this issue.