Can we get this to work with Buildah/podman rather then being Docker Centric

[rhatdan]

There is no Docker in RHEL8 so this package will not work there.

s2i in OpenShift 4.1 is based on Buildah, shouldn't this package be based on it also?

[bparees]

s2i builds in openshift 4.1 are based on the --as-dockerfile flow. The s2i code (as vendored into/used in openshift) doesn't actually invoke any buildah libraries directly.

We don't currently have any plans to invest in re-implementing the "traditional" s2i flow to directly communicate with additional container runtimes because the "generate a dockerfile, then build the dockerfile w/ your image building tool of choice" gives us more insulation than having to implement a "container runtime driver" for each additional container runtime we want s2i to be able to drive.

If someone else has the time/resources to contribute the work, we'd probably accept it, but it's a significant refactor to:

1. abstract all the places where s2i directly talks to docker today (creating containers, starting them, injecting content, monitoring container progress, committing images w/ modified metadata)
2. implement the buildah/podman based equivalents of that logic

/cc @adambkaplan @smarterclayton

[smarterclayton]

Seems reasonable Ben

…

On Thu, May 16, 2019 at 9:57 AM Ben Parees ***@***.***> wrote: s2i builds in openshift 4.1 are based on the --as-dockerfile flow. The s2i code (as vendored into/used in openshift) doesn't actually invoke any buildah libraries directly. We don't currently have any plans to invest in re-implementing the "traditional" s2i flow to directly communicate with additional container runtimes because the "generate a dockerfile, then build the dockerfile w/ your image building tool of choice" gives us more insulation than having to implement a "container runtime driver" for each additional container runtime we want s2i to be able to drive. If someone else has the time/resources to contribute the work, we'd probably accept it, but it's a significant refactor to: 1. abstract all the places where s2i directly talks to docker today (creating containers, starting them, injecting content, monitoring container progress, committing images w/ modified metadata) 2. implement the buildah/podman based equivalents of that logic /cc @adambkaplan <https://github.com/adambkaplan> @smarterclayton <https://github.com/smarterclayton> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#966?email_source=notifications&email_token=AAI37J43YIN62OBJGYCNZCTPVVR4TA5CNFSM4HNMTEQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVR4PYI#issuecomment-493078497>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI37J2EQOI5HYOVEZLU5JDPVVR4TANCNFSM4HNMTEQA> .

[rhatdan]

Can we deprecate this repo then?

[adambkaplan]

Feels like it is worth doing a survey of the image building tools to see which ones support a Dockerfile as input. That could motivate, say, an s2i v2 that produces a Dockerfile and build context that is consumed by the chosen image builder.

[jmtd]

s2i builds in openshift 4.1 are based on the --as-dockerfile flow

That's a useful hint, thanks. My images (openjdk-?-rhel?) don't have /usr/libexec/s2i/assemble so fail for this. but last I checked a basic s2i worked quickstart worked in OCP 4.1.

s2i in OpenShift 4.1 is based on Buildah,

TIL this s2i code isn't in OCP 4.1.

[bparees]

That's a useful hint, thanks. My images (openjdk-?-rhel?) don't have /usr/libexec/s2i/assemble so fail for this. but last I checked a basic s2i worked quickstart worked in OCP 4.1.

if your image doesn't have an assemble script then you have to supply one via one of the alternate mechanisms (include it in your source repo, or pass it in as an additional argument). Either of those flows should work with --as-dockerfile but it's possible we missed something when implementing it as the primarily goal was supporting openshift, not the raw CLI invocation. Can you open a separate issue telling us what you're doing and what you're seeing?

TIL this s2i code isn't in OCP 4.1.

not sure how you're defining "this". Code from this repo is in OCP 4.1, but we only use the bits of this repo's code that generate a Dockerfile, not the bits that launch/commit containers.

[klmcwhirter]

Fedora 31 uses Linux cgroups v2. And so the docker daemon won't start.
The s2i executable insists on using /usr/bin/docker (perhaps a security reason - trimmed PATH or other mechanism).

But this causes make test to fail on Fedora 31 systems.

FYI..

[rhatdan]

Can you install podman-docker?

[bparees]

i guess you could always symlink /usr/bin/docker to something that works for now.

[rhatdan]

This is what the podman-docker package does. It basically sets up link from docker command to run podman commands, as well as docker man pages to show Podman man pages.

[klmcwhirter]

Can you install podman-docker?

Installing source-to-image uninstalls the podman-docker package.

Trying to install podman-docker after the fact produces the following:

sudo dnf install podman-docker
Last metadata expiration check: 0:38:38 ago on Sun 05 Jan 2020 11:22:12 AM PST.
Error: 
 Problem: problem with installed package moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
  - package podman-docker-2:1.6.1-5.fc31.noarch conflicts with moby-engine provided by moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
  - package podman-docker-2:1.6.1-5.fc31.noarch conflicts with docker provided by moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
  - package podman-docker-2:1.6.1-5.fc31.noarch conflicts with docker-latest provided by moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
  - conflicting requests
  - package podman-docker-2:1.6.2-2.fc31.noarch conflicts with moby-engine provided by moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
  - package podman-docker-2:1.6.2-2.fc31.noarch conflicts with docker provided by moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
  - package podman-docker-2:1.6.2-2.fc31.noarch conflicts with docker-latest provided by moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

Tried the following:

• sudo dnf install --skip-broken --best --allowerasing podman-docker - Nothing to do
• sudo dnf install --skip-broken --allowerasing podman-docker - Nothing to do
• sudo dnf install --allowerasing podman-docker results in an attempt to remove source-to-image:

sudo dnf install --allowerasing podman-docker
Last metadata expiration check: 0:44:38 ago on Sun 05 Jan 2020 11:22:12 AM PST.
Dependencies resolved.
=====================================================================================================================
 Package                     Architecture       Version                                    Repository           Size
=====================================================================================================================
Installing:
 podman-docker               noarch             2:1.6.2-2.fc31                             fedora               69 k
Removing dependent packages:
 moby-engine                 x86_64             18.09.8-2.ce.git0dd43dd.fc31               @fedora             168 M
 source-to-image             x86_64             1.1.7-6.fc31                               @fedora              13 M

Transaction Summary
=====================================================================================================================
Install  1 Package
Remove   2 Packages

Total download size: 69 k

Changing /usr/bin/docker to be a symlink to /usr/bin/podman will do nothing because the s2i executable attempts to talk to the docker daemon directly.
See pkg/docker/docker.go.

Seems like support for the Redhat move to cgroups v2 needs to be supported directly. Until then source-to-image is unusable on Fedora,

It appears this is being worked on in PR 996.

I'll setup a CentOS vm for now.

Thanks.

-k

[bparees]

Changing /usr/bin/docker to be a symlink to /usr/bin/podman will do nothing because the s2i executable attempts to talk to the docker daemon directly.

yes that's well understood, i thought your concern was that it was attempting to use the binary directly (you said The s2i executable insists on using /usr/bin/docker (perhaps a security reason - trimmed PATH or other mechanism).).

s2i depends on the docker socket and there are no plans to change that beyond introducing the "--as-dockerfile" option to avoid the use of a container engine entirely, as explained in #966 (comment)

You can choose the docker socket that s2i invokes, however, enabling to you to, among other things, use a remote docker socket(such as running on a VM): https://github.com/openshift/source-to-image/blob/master/pkg/cmd/cli/cli.go#L35

[klmcwhirter]

Changing /usr/bin/docker to be a symlink to /usr/bin/podman will do nothing because the s2i executable attempts to talk to the docker daemon directly.

yes that's well understood, i thought your concern was that it was attempting to use the binary directly (you said The s2i executable insists on using /usr/bin/docker (perhaps a security reason - trimmed PATH or other mechanism).).

s2i depends on the docker socket and there are no plans to change that beyond introducing the "--as-dockerfile" option to avoid the use of a container engine entirely, as explained in #966 (comment)

You can choose the docker socket that s2i invokes, however, enabling to you to, among other things, use a remote docker socket(such as running on a VM): https://github.com/openshift/source-to-image/blob/master/pkg/cmd/cli/cli.go#L35

Well that is just silly. If RedHat is commiting to cgroups v2 and not supporting docker on their OSes. Then their OpenShift product (in which source-to-image is a part) should embrace that fact as well.

I thought that went without saying.

Like i said, I'll wait for the --with-builder options being worked on in PR 996.

I am not sure where you are getting your information 'there are no plans to change that'. I would be careful not to disseminate misinformation. A comment in a PR should be treated as casual conversation. We are privileged to see the discourse. But the people in that conversation are not decision makers. A company (my company is a large RedHat customer) cannot base their strategy on those kinds of conversations,

Since it is not currently possible for s2i builder images to be built using the source build strategy in OpenShift this causes us to have to build them outside of the cluster and push them to our registries "manually". Hence this problem.

As I said earlier, until the --with-builder option is available I will work in CentOS 7. No harm - no foul.

[bparees]

Well that is just silly. If RedHat is commiting to cgroups v2 and not supporting docker on their OSes. Then their OpenShift product (in which source-to-image is a part) should embrace that fact as well.

s2i is evolving to not be dependent on docker, that is the direction of the "--as-dockerfile" flag, and is how openshift v4 supports s2i w/o requiring a docker daemon. (s2i strategy builds in OCP4 use the s2i --as-dockerfile codepath to generate a dockerfile, and then use buildah to build the image).

see these PRs for how the s2i CLI tool will be evolving to also make this the first class direction, though the s2i cli tool is not part of the openshift product, it's just a handy way to develop/test s2i builder images outside of openshift:
#1003
#1002

I am not sure where you are getting your information 'there are no plans to change that'. I would be careful not to disseminate misinformation.

I'm basing it on my comment in this issue(#966 (comment)) and the acknowledgement from @smarterclayton who is the architect for openshift. But certainly if you would like to have a deeper product-direction discussion, submitting an official RFE would be a more suitable/official channel to discuss it.

To be clear, when I say there are no plans to change it, I am saying there are no plans for the s2i cli binary to have low level integration with other container runtimes(as it had with docker). There are plans to make s2i work with other container runtimes by delegating the image building to those runtimes, after it generates a suitable working directly+dockerfile (and it can already do this today with a little glue work by the end-user). See the aforementioned PRs, though it sounds like you may already be aware of them.

I cannot speak to what plans to exist(if any) to either move docker to support cgroups v2, or otherwise update fedora to support docker. (Of course you can also move fedora back to cgroups v1 if you want to use that to allow docker to run: https://www.redhat.com/sysadmin/fedora-31-control-group-v2)

But the people in that conversation are not decision makers.

In this particular case, they were/are, but again certainly if you have product-direction concerns about how this might impact your organization, we'd be happy to take up the conversation in a more formal RFE channel. I do not think you need to be concerned however, as the direction for s2i is to move away from being dependent on docker (but at the same time also moving away from s2i directly producing images, but rather to outsource that to your image building tool of choice). We are committed to maintaining compatibility such that s2i builder images will continue to work even as the underlying container runtime technologies evolve (as we did when we moved off docker in ocp v4)

Since it is not currently possible for s2i builder images to be built using the source build strategy in OpenShift this causes us to have to build them outside of the cluster and push them to our registries "manually". Hence this problem.

hmmm

1. an s2i builder image is an image which contains an assemble script and which can be used with s2i (either the cli or the openshift s2i build strategy) to product a new application image. s2i builder images themselves (i.e. a base image that includes your language runtime/compilation tools and assemble script) is normally built from a Dockerfile using docker, buildah, or some other image building tool. It is not normally built using s2i itself. (but can be built within openshift using the docker strategy). So i'm not positive i understand your scenario.

2. I'm not sure why you say that images can't be built in openshift since openshift supports both the docker + source strategies, and does not require a docker socket on the host (as of v4. V3 still required a docker daemon for any image builds). But that is independent of what the s2i cli tool does/doesn't support, so if your issue is what what you can/can't do in your openshift cluster, we should take this discussion to an issue (or rfe or bugzilla) filed against openshift and not this repo (which is primarily about the s2i cli tool being used independently of an openshift cluster/build-api).

As I said earlier, until the --with-builder option is available I will work in CentOS 7. No harm - no foul.

with "--with-builder" option more or less exists today. you run s2i with the --as-dockerfile argument and then invoke your dockerfile-supporting image build tool of choice on the output. The "--with-builder" argument is just going to streamline that flow.

[klmcwhirter]

that is the direction of the "--as-dockerfile"

That sounds suspiciously like the Dockerfile build strategy as opposed to the Source Build Strategy - I guess I have some reading t do.

we'd be happy to take up the conversation in a more formal RFE channel

Fair enough.

1. ...

not following you - isn't that the point of the s2i project?

2. ...

our experience - per your suggestion I will ask in official channels, Maybe we got this wrong.

Not following your last statement exactly. Again official channels will help,

But to get my image builder tested right now with OpenShift 3.11 - I need to resort to using CentOS 7. That is working well.

[bparees]

That sounds suspiciously like the Dockerfile build strategy as opposed to the Source Build Strategy - I guess I have some reading t do.

think of it as the dockerfile build strategy but with a highly opinionated/constrained dockerfile input(controlled by s2i, not the user). But the net result is the same user experience (provide source code + an s2i builder image, get a runnable application image) and the same security constraints (namely, doesn't allow you to run commands as root in openshift..of course on the cli anyone can edit the dockerfile before building it to change the user).

not following you - isn't that the point of the s2i project?

The point of the s2i project is to take existing "s2i builder images" (images which know how to turn source code for a particular language into a runnable image that will run that source code/application) and combine them with user provided source code to produce a runnable application image.

The s2i builder images themselves (e.g. s2i-nodes, s2i-ruby, etc) are typically built by someone writing a Dockerfile and docker-building it, e.g.: https://github.com/sclorg/s2i-nodejs-container/blob/master/8/Dockerfile

our experience - per your suggestion I will ask in official channels, Maybe we got this wrong.

From your last statement I guess you are trying to run v3.11 which would indeed require a docker daemon for builds (s2i or docker) to work. v4 does not have this requirement. I'd strongly encourage you to start exploring v4 if possible.

[spolti]

And what about manual s2i builds? I still trying it but no success so far.
symlink podman to /usr/bin/docker and installing podman-docker didn't work.

it still looking for /var/run/docker.sock

Using runtime-image and --as-dockerfile is not allowed though.

Any ideas?

[bparees]

Using runtime-image and --as-dockerfile is not allowed though.
Any ideas?

i'm afraid not, we did not carry the runtime-image feature forward into --as-dockerfile

you'll need a legitimate docker daemon (due to the need to talk to the docker socket as you noted) if you want to leverage that feature.

[rhatdan]

Docker socket support is coming to Podman (Actually in Master branch now, at least partially)

[pvalena]

Docker socket support is coming to Podman (Actually in Master branch now, at least partially)

I've tested this (took current Fedora rawhide podman), with running the socket:

$ sudo podman system service --time=0 unix:///$PWD/podman.sock

---

And specifying it for (using any ruby image):

$ DEBUG=true sudo s2i build --pull-policy=never -c -U unix://../../podman.sock https://github.com/pvalena/s2i-ruby-container.git --context-dir=2.7/test/puma-test-app/ localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4 ruby-test-27-rhel-db
Checking if image "localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4" is available locally ...
Checking if image "localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4" is available locally ...
Your branch is up to date with 'origin/master'.
Submodule 'common' (https://github.com/sclorg/container-common-scripts.git) registered for path 'common'
Cloning into '/tmp/s2i020238813/upload/tmp/common'...
Submodule path 'common': checked out '9e8688d13c8bde35a8daaaf026035b66bced4204'
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
Build failed
ERROR: An error occurred: non-zero (13) exit code from localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4

---

Maybe the error it's releated to this?

$ sudo podman run --rm -it localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4 /usr/bin/bash
Error: container_linux.go:349: starting container process caused "exec: \"container-entrypoint\": executable file not found in $PATH": OCI runtime command not found error

Any idea what is blocking it?

---

Notes:
I took source-to-image from Fedora rawhide and rebuilt it without the dependency on docker.

With local folder instead of git URL the error is the same.

The image was imported like so:

$ podman save --compress -o ../../rhscl_ruby-27-rhel7_20200621-3e76ec4.txz localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4
$ sudo podman load -i ../../rhscl_ruby-27-rhel7_20200621-3e76ec4.txz localhost/rhscl/ruby-27-rhel7:20200621-3e76ec4

[jasinner]

For anyone else who's wondering '--as-dockerfile' is available in source-to-image 1.3.0, not 1.1.0 as shipped in the Fedora 31 repository.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[tomcruise81]

/remove-lifecycle stale

[adambkaplan]

/lifecycle frozen

This is something to consider for an s2i v2.

[erikerlandson]

Just dropping in to observe that it is now 2021, and I'm running fedora 33, where s2i is still on 1.1, and so (per above, cgroups v2, etc) there is still no out-of-box s2i that works.

[klmcwhirter]

FYI - I recently worked with a Red hat engineer assigned to our company as an Open Shift SME. He told me not to rely on S2I but use Jenkins instead to build the image with more control. He suggested that S2I is not production worthy - it should only be used for prototyping. So much for DevOps. From RedHat perspective it is all about Ops. Who cares about DX. Apparently, they do not. I am abandoning use of Red Hat where I can and moving to vanilla Kubernetes. I am done with this fight. Red Hat has become Big Blue Hat. Sad ...

…

-k

On Thu, Feb 18, 2021, 5:13 AM Erik Erlandson ***@***.***> wrote: Just dropping in to observe that it is now 2021, and I'm running fedora 33, where s2i is still on 1.1, and so (per above, cgroups v2, etc) there is still no out-of-box s2i that works. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#966 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKFJ3SPTRSSQNCTAE66CVTS7UHAVANCNFSM4HNMTEQA> .

[frenzymadness]

Even I consider it a sad fact as well that the package in Fedora is from mid-2017 and is pretty useless, I'll try to be more constructive and help those who need to find a way to work with these images on Fedora:

• you can download working binary from Github
• the newer versions provide --as-dockerfile option so you do not need Docker anymore and you can build it in podman
• s2i-* images still have a lot of additional value and I'd honestly say that they are well maintained.
• the images also recently gained docs about how to use them as a base images without s2i tools/scripts at all, for example, Python container: https://github.com/sclorg/s2i-python-container/tree/master/3.8#building-an-application-using-a-dockerfile

Disclaimer, I'm a maintainer of the Python container and I've been frustrated many times about the status of s2i in Fedora so I've found workarounds. I'd like to help with the package and the application itself but I'm Pythonista and I don't know Go well enough.

[bparees]

The team that maintains s2i itself is not the team that packaged it for fedora, which is what has lead to the fedora package going largely unmaintained. We'll see if we can get that team to refresh the package.

[erikerlandson]

I downloaded the latest (1.3) from github, which is pretty easy to do. I'm not sure what the "intended" roadmap is: while I believe maintaining an actual s2i command line facility is useful, possibly the intention is that people use oc new-build instead? My one issue with that is, it requires access to a cluster, which seems over-engineered for workflows where one is just building an image and not immediately deploying it.

[erikerlandson]

I see the design advantages of putting the boundary at --as-dockerfile - I think it might be useful to support a concept like --dockerfile-builder <build-tool> where <build-tool> could be docker, or podman, or any other third party program capable of building the output dockerfile as an image, without having to explicitly run a separate podman build ... step after s2i --as-dockerfile ...

[adambkaplan]

@erikerlandson for a while we've discussed an "s2i v2" that allows the build tool to be selected, almost exactly as you described. In that process we would drop the explicit dependencies on docker in favor of a loose coupling that calls docker build, podman build, etc. Unfortunately those efforts have stalled.

See #1031

[erikerlandson]

@adambkaplan that seems like a good toolchain design 💯

[hhorak]

The team that maintains s2i itself is not the team that packaged it for fedora, which is what has lead to the fedora package going largely unmaintained. We'll see if we can get that team to refresh the package.

I can speak for a team who used to have some interest in s2i in Fedora, because we've had it in the RHSCL channel. The initial goal was to have the tool that can be used to work with s2i images like python/node/etc without OpenShift, but...

With RHEL-8 and podman, the use case got limited to the --as-dockerfile, which didn't look like something useful, so for testing purposes we rather generate a Dockerfile different way (see https://github.com/sclorg/s2i-light for inspiration) and for users we recommend to write their Dockerfile and call assemble script there (see https://github.com/sclorg/s2i-ruby-container/tree/master/2.7#31-to-use-the-source-to-image-scripts-and-build-an-image-using-a-dockerfile-create-a-dockerfile-with-this-content).

So, the bottom line is we don't have any big interest in s2i in Fedora because the value of it is very low. Feel free to submit a patch and I can commit+build, but I don't have time nor skills to do it myself. I actually tried already once to update to 1.3.x and after two days of fighting with golang packaging I gave up.

[erikerlandson]

In case anyone finds it useful, I hacked together a script that runs s2i build ... --as-dockerfile on a given src directory and then calls podman on the result. Note, it operates on the "raw" contents of the given src-dir (not latest-commit). It has been working decently for me so far:

https://gist.github.com/erikerlandson/e2dcd42397e5b7f589591fbefe989088

[yselkowitz]

The team that maintains s2i itself is not the team that packaged it for fedora, which is what has lead to the fedora package going largely unmaintained. We'll see if we can get that team to refresh the package.

If neither unbundling vendored deps nor EPEL 8 compatibility is required, then I have this:

https://src.fedoraproject.org/fork/yselkowitz/rpms/source-to-image/c/f8eb42bdbcdf279affde0cd5144c7f04d74a9c14?branch=rawhide

[erikerlandson]

@yselkowitz 🎉 is it too late to sneak this into f34? 😁

[yselkowitz]

@yselkowitz tada is it too late to sneak this into f34? grin

Not too late: https://koji.fedoraproject.org/koji/buildinfo?buildID=1713696

[klmcwhirter]

I have tried every hack mentioned - i still have to rely on vmachines in order to get my work done. Red Hat's insistence on cgroup v2 - meaning docker does not work - means too much low level tweaking (none works) - means I cannot get work done. I am moving to Debian or Ubuntu. Which means openshift is a non-starter, K8S vanilla is where I am already working as guided by my company's architecture team. Red Hat blew it. they had a chance to make a developer play. At my company they are done, They sold the ops folks for millions. But no developers wants to use it. Very senior leadership either because of DR scenarios, As I said earlier, Red Hat has become Big Blue Hat - they are done.

…

-k

On Mon, Feb 22, 2021 at 9:16 AM Yaakov Selkowitz ***@***.***> wrote: @yselkowitz <https://github.com/yselkowitz> tada is it too late to sneak this into f34? grin Not too late: https://koji.fedoraproject.org/koji/buildinfo?buildID=1713696 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#966 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKFJ3XFCH7WTT4NROAPBA3TAKGQDANCNFSM4HNMTEQA> .

[bparees]

@klmcwhirter thank you for feedback about the challenges of using s2i with cgroups v2. Beyond that(which the the team has already made is intended to be addressed by generating dockerfiles + using other container build technologies), this issue is not an appropriate place for expositions about the larger product ecosystem or product strategy choices by redhat or ibm. The team that works on s2i has no input on cgroups v2 or the choices of various distributions to adopt, or not adopt, it as a default.

I'm going to close this issue as it seems to be attracting unproductive+unrelated discussion. #1031 and #1003 continues the discussion of adding explicit buildah support to s2i (but still likely via a "generate a dockerfile + invoke buildah on it" mechanism, not native/direct api support as was done in the original s2i implementation)

[klmcwhirter]

That is fine. But without S2I builder images as in version 3 there is no compelling reason - from a developer's perspective - to use OpenShift. That WAS the killer feature for using OpenShift over vanilla K8S. So I cannot get OpenShift engineers to listen and now cannot get OpenShift developers to listen either. I have been a Red Hat customer since they first started in the mid '90s. I am saddened by all of this. But things do change.

…

-k

On Wed, Feb 24, 2021 at 7:06 AM Ben Parees ***@***.***> wrote: @klmcwhirter <https://github.com/klmcwhirter> thank you for feedback about the challenges of using s2i with cgroups v2. Beyond that(which the the team has already made is intended to be addressed by generating dockerfiles + using other container build technologies), this issue is not an appropriate place for expositions about the larger product ecosystem or product strategy choices by redhat or ibm. The team that works on s2i has no input on cgroups v2 or the choices of various distributions to adopt, or not adopt, it as a default. I'm going to close this issue as it seems to be attracting unproductive+unrelated discussion. #1031 <#1031> and #1003 <#1003> continues the discussion of adding explicit buildah support to s2i (but still likely via a "generate a dockerfile + invoke buildah on it" mechanism, not native/direct api support as was done in the original s2i implementation) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#966 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKFJ3QVOGATXZHXQI6AV63TAUIYHANCNFSM4HNMTEQA> .

[hhorak]

But without S2I builder images as in version 3 there is no compelling reason - from a developer's perspective - to use OpenShift. That WAS the killer feature for using OpenShift over vanilla K8S.

@klmcwhirter This ^ seems like a misunderstanding; there are still S2I images in OpenShift 4.x and S2I is still a supported strategy even in OpenShift 4.x on RHEL-8. The only change is that s2i tool running as a standalone tool (outside of OpenShift) is not a recommended use case on RHEL-8.