Interest/Feedback in Broader Stack Support

[sophiewigmore]

Recently, we've seen an uptick in requests (example 1, example 2, example 3) for Focal (Ubuntu 20.04) support, ARM64 support, and more flexible stack-creation offerings.

Due to the amount of work/resources required to create and maintain multiple sets of stacks we've been hesitant as a project to do so in the past. It would be helpful to understand use cases and track the full extent of interest amongst the community.

The goal of this discussion is to get feedback and specifics about:

• What stack/base image you would like to see support for
• Why you need support for this stack? Does your requirement come from an organization?
• Is it a blocking request or a nice-to-have?
• Do you have interest in contributing to Paketo stacks-related efforts?

[kevin-ortega]

I would like to see support for UBI stack/base images.

Many Liberty App server users exclusively use UBI and some (Ford) would not use Paketo until we were able to provide a UBI solution. This was the primary reason we initial abandoned developing a Liberty buildpack.

Having UBI support will allow the Liberty buildpack to more natively provide ubi images without having to manually create build and run images, a builder or project.

[dmikusa]

What stack/base image you would like to see support for

ARM64

Why you need support for this stack? Does your requirement come from an organization?

I have seen/spoke with a number of Spring Boot users interested in ARM64 support. They are receiving Macbook M1s and the experience with buildpacks is sub-par without native ARM64 images. For a standard Java/JVM app, it's not too bad, a bit slower, but for a native image Java app you can almost double the time it takes for a build trying to run x86 images.

Is it a blocking request or a nice-to-have?

For native-image users, which is a growing segment it's unusably slow.

Do you have interest in contributing to Paketo stacks-related efforts?

Yes. If you are also looking for ARM64 support, for this or any other reason, and interested in helping please 👍 this or reply so we can see who's interested.

[TomBeckett]

I would switch over to ECS ARM 64 tomorrow if i could!

[jpena-r7]

+1 for ARM64 support. We're still building x86 containers, but it's only a matter of time before ARM is required.

I would like to see support for a redhat-based stack. I don't have a specific requirement for it at the moment, but it's not unthinkable that a third-party or audit requirement mandates that an app be deployed on redhat rather than ubuntu. This is a nice-to-have at this point, but others may already have this requirement.

I would like to see support for any (*) stack being used by buildpacks more broadly.

While testing a redhat-based stack I created I noticed that the java buildpack supports any stack while python, and possibly others, only support bionic. I understand that package management and even package names differ between distros. Assuming the redhat stack has installed package metadata added as a mixin label, similar to the bionic stack, dependencies could be checked by looking for package names from both distros rather than bionic only. Or it could be done as regex, if that is supported. Or some other way altogether. Regardless of implementation, it would allow for broader stack support and is likely a pre-requisite.

• More flexible stack-creation offering.

I have been working on creating a customized stack and forked the stacks repo to allow the installation of additional deb packages. These changes are specific for my needs, but it could be beneficial for other users to create their own stacks if they are required to install additional packages. The tooling to build the stack is very helpful and picks up the additional packages automatically, which is a big plus.

I would potentially be interested in contributing to stacks-related efforts.

[shresthaujjwal]

+1 distroless like python support not just bionic

[sophiewigmore]

@jpena-r7 RE: * wildcard stack support, I believe pack CLI 0.24.1 has resolved an issue that prevented us from using the wildcard stack in some cases, so hopefully we can see this happen more across other buildpacks.

[loewenstein]

I would like to see support for more Ubuntu LTS versions (I've put this into the roadmap discussion as well.

I've seen Canonical stating "won't fix" based on the lack of a compatible fix for CVEs that had an unmodified base score of >7 on the Bionic security information page. That's pretty unfortunate and leaves app developers with the tough challenge to figure out on their own if the vulnerability can be ignored in their app's context.

Also, if approaching developers currently using Dockerfiles, it's likely to find recent LTS versions being used and going back to an older LTS might be an unacceptable effect of adopting buildpacks.

Quicker adoption of new LTS versions would resolve both, but on the other hand side I can see newer versions seeing more zero-days - some developers might prefer the older LTS.

Maybe supporting 18.04 until April 2023 would be excessive, but we should ideally support 20.04 and 22.04 until 24.04 comes out and we should definitely support 24.04 once it comes out.

[loewenstein]

Forgot to mention, we are happy to contribute to Paketo where and if possible.

[sophiewigmore]

@loewenstein thanks for the explanation. I'm not sure if you've seen paketo-buildpacks/rfcs#172, but there is a proposal to support 2022.04 in the works. This doesn't directly address your concern about supporting more versions in general (like 20.04) but as someone pointed out on the roadmap discussion, paketo-buildpacks/rfcs#169 may make it simpler for users to support their own in between versions

[loewenstein]

@sophiewigmore The move to 22.04 indeed doesn't solve the issue, only 24.04 could do that ;)
Better/easier support for building our own Stacks is certainly appreciated, but I would prefer not building our own Stack in the first place. Building it isn't the issue anyway - the Paketo buildpacks have to be tested against. Also, as long as Paketo buildpacks require a specific stack, we would need to maintain forks if only for the sole purpose of changing the supported stack in the buildpack.toml file.

All of that would be done potentially multiple times, by multiple Paketo consumers. I'd very much prefer doing it in the community instead.

[sophiewigmore]

Right, the specific stack in our buildpacks is linked to how we do our dependencies, since they're compiled against an OS. If we handle that to be OS agnostic, then the option for supporting * as the stack in our buildpacks becomes much more viable. Some buildpacks can be moved over now, but it's not ubiquitous

[shresthaujjwal]

For my organization, what is making it difficult to adopt buildpack is we will be forced to maintain our own stacks or maintain the fork of buildpacks stacks, we need ability to install and manage our own packages and not rely on open source contributions eg: https://github.com/paketo-buildpacks/stacks/blob/main/packages/base/build
We need lot of control on what goes inside the stacks and create-stack cli needs to be verify flexible and have support for our internal corporate proxy.

+1 for arm64 and ubuntu 20 support.

I'm open for contributions and help where needed.

[sophiewigmore]

@shresthaujjwal @jpena-r7 If the Stack Descriptor RFC lands, it will hopefully be easier for folks to leverage our tooling to support alternative stacks, and for us as a project to support different stacks

[shresthaujjwal]

thanks @sophiewigmore, sorry was out on leave for some time. just following up on this. So looks like the RFC has been approved and merged. What is the next step, is anyone already working on this where can i track this progress ?

[sophiewigmore]

@shresthaujjwal welcome back! Yes, so the stack descriptor RFC is merged and has been implemented. The jam create-stack command outlined there is available in jam as of v1.3.0 so that can be used to create stacks if you wanted to try that out.

In terms of building other stacks that leverage this tooling, the work to create Jammy Jellyfish (2022.04) stacks is in progress now! @fg-j and @robdimsdale might be able to point out anything in this space that they could use help with.

In terms of ARM64 support, that will likely come later since we are working on some other work around our dependencies that is blocking.

[shresthaujjwal]

@sophiewigmore this is awesome, thank you for quick response, i will try this out and let you know if there is any questions.

[sophiewigmore]

@shresthaujjwal there's usage documentation in progress now, which will hopefully be available soon on paketo.io that should help as well.