> should we / could we migrate the primary/default container to distroless? Is this an intermediate step toward that? Or is it necessary to maintain both and for how long?
I think that this would be a hard migration to force on users, especially for Python containers where there is a reasonably large gap between the distroless + debian images we publish (I assume this is what you mean by Hyrum's dead end?). I also do think each offers a real value prop, though, independent of the migration cost - distroless is great for extra security conscious users, debian is great for folks who want more things to just work out of the box without thinking about dependencies/custom containers too much. I do not think it will take much to maintain these, so I'm -1 on moving towards a full migration/deprecation. I'd probably even be -1 on trying to change the default, mostly because it's not obvious to me that distroless is the better default for most users. On Tue, Nov 26, 2024 at 9:43 AM Kenneth Knowles <k...@apache.org> wrote: > +1 to the work and +1 to the use of a separate repo, given the framing > that it is an optional variant that will have a sequence of releases in > parallel to the primary containers. > > But have to ask: should we / could we migrate the primary/default > container to distroless? Is this an intermediate step toward that? Or is it > necessary to maintain both and for how long? (for a reason other than > Hyrum's Dead-end, please) > > Kenn > > On Tue, Nov 26, 2024 at 9:26 AM Danny McCormick via dev < > dev@beam.apache.org> wrote: > >> Thanks - I'm +1 to both doing this work and the naming convention. The >> main naming alternative I can think of is using tags for distroless, aka >> apache/beam_python3.9_sdk:2.61.0-distroless (and probably also >> apache/beam_python3.9_sdk:latest-distroless), but I think that having >> separate repos is probably a little bit cleaner for vulnerability tooling >> and vulnerability-based policies. Overall, I don't think there's a huge >> difference (and I've seen both approaches used), but I like the repo >> approach a bit more. >> >> Thanks, >> Danny >> >> On Mon, Nov 25, 2024 at 5:31 PM Damon Douglas <damondoug...@apache.org> >> wrote: >> >>> Hello everyone, >>> >>> Work is currently underway <https://github.com/apache/beam/issues/32815> >>> to build support for distroless container images >>> <https://github.com/GoogleContainerTools/distroless>. The purpose of >>> this message is to query any concerns over their naming convention, where >>> simply "_distroless" is added as a suffix. Currently, as an example, for >>> the Apache Beam Python 3.12 SDK, we publish apache/beam_python3.12_sdk >>> <https://hub.docker.com/r/apache/beam_python3.12_sdk> and for Java 17, >>> we publish apache/beam_java17_sdk >>> <https://hub.docker.com/r/apache/beam_java17_sdk>. The distroless >>> variants of these aforementioned will be >>> apache/beam_python3.12_sdk_distroless and >>> apache/beam_java17_sdk_distroless, respectively. Please let me know if you >>> have any concerns with the following proposed distroless variants. Note >>> that not all versions of Python and Java will be supported. >>> >>> apache/beam_python3.9_sdk_distroless >>> apache/beam_python3.10_sdk_distroless >>> apache/beam_python3.11_sdk_distroless >>> apache/beam_python3.12_sdk_distroless >>> apache/beam_java17_sdk_distroless >>> apache/beam_java21_sdk_distroless >>> >>> Best, >>> >>> Damon >>> >>
