Why do you plan to break your potential customers infrastructure on the 28th?

[fungiboletus]

What steps will reproduce the bug?

I’m sorry, I don’t get the logic behind moving everything to bitnamilegacy and slowly breaking so many systems.

It’s not too late to change strategy. I understand that you want to commercialise the secure images. Fair enough. I’m outpriced, but that’s ok. What I don’t understand is why you want to break existing deployments when you technically don’t have to.

I’m just a random user of the Bitnami Helm charts, but I hope that if enough people communicate their concerns about the upcoming disaster, whoever is behind this decision will change their minds. Thanks.

[cmcga1125]

The transition to Bitnami Secure Images introduces a critical challenge for the broader user community. While the goals of enhancing security and promoting software supply chain integrity are commendable, the proposed timeline and process are likely to have a significant and negative impact on the industry.

The two-week migration window, starting on August 28th, is unrealistically short for enterprise-scale adoption. For many organizations, migrating production workloads from the public catalog to the new "Bitnami Legacy" repository—or, more complexly, adopting the new hardened images—is not a simple task. This process involves:

• Extensive validation and testing to ensure application compatibility with the new images.
• Updating CI/CD pipelines and deployment scripts that rely on specific, versioned image tags.
• Coordination across multiple teams, including development, DevOps, and security, to manage the transition smoothly.

The swift deprecation of non-hardened, Debian-based images and the removal of versioned tags from the public catalog will introduce unnecessary risk and potential for outages across the cloud-native ecosystem. This abrupt change forces users into a "latest-only" model for development, which can lead to instability and unexpected behavior.

This approach, while well-intentioned, could ultimately drive users away from the Bitnami ecosystem. The burden of this rapid transition, coupled with the risk of service disruption, may lead organizations to seek more stable and predictable alternatives for their container images, undermining the very continuity that Broadcom and Bitnami aim to ensure.

[cruizba]

This is too disruptive, it is not going to end well...

Why deprecate and remove the entire registry? Why not creating a new one? I think this is more disruptive to your current user base than the potential new users that may want to use secure images...

[wjimenez5271]

First of all, we understand these changes may cause disruption, and we truly regret the impact this can have on existing deployments. The decision to copy the existing catalog to bitnamilegacy and focus our efforts on the new Bitnami Secure Images at bitnami was not taken lightly. The way Bitnami has been operating is no longer sustainable, and in order to continue our mission, changes had to be made. Our goal is to continue delivering up-to-date, maintained, and secure software going forward. We evaluated several alternatives, each with pros and cons, and concluded that this approach offered the best balance. It allows a smoother transition to Bitnami Secure Images, while community users can still access the existing images simply by changing the registry from bitnami to bitnamilegacy.

Please also note that the source code for the container images and Helm charts remains open and licensed under Apache 2.0. This means anyone using Bitnami can continue to do so; they just have to build the software artifacts. In this way, existing users who cannot or do not want to move to Bitnami Secure Images still have a path forward. We've sought to understand the impact of Bitnami users building the images/charts in their own pipelines, and thus far, no one has told us that taking on that responsibility is a significant burden. We've observed many of our users already operate build infrastructure that is producing other OCI assets, and therefore adding Bitnami to that system is a relatively incremental effort.

That being said, we are always open to learning more from our users about their challenges. The best way to achieve a better understanding is to have a conversation. @cmcga1125, would you be open to a Zoom session to further discuss? We would greatly appreciate any time you can spare to help us raise our understanding of challenges and specific use cases you are thinking about.

Again, appreciate your feedback, and we will share this with the leadership. Thank you for taking the time to share your thoughts on Bitnami and for your care and attention to the community.

[strowk]

@wjimenez5271 , wouldn't it be less problems for a lot of people in the internet, while still fulfilling the purposes you describe, if bitnami:<tag> images would remain for what you call "legacy" (would just stop updating) and new stuff would go to, f.e bitnamisecure:<tag> ?

I realize that the desire to keep your efforts sustainable probably requires some users to pay for this new premium stuff, and some people disrupted by requirement to switch to bitnamilegacy might become those paying users, but is this off chance REALLY worth disrupting so many other people?

[fungiboletus]

Thanks for you answer, but I still don’t understand.

From my user point of view, your currently selected solution is very far from being the best balance. You have insights I don’t have, bit still, the cons of breaking potential lucrative customers’ production systems during summer with a short period notice should be a lot heavier than whatever you put on the pros side.

[cruizba]

@wjimenez5271 will new and old community images be Open Source and Apache License 2.0?

[pabloFuente]

This is a strange, disruptive, and unnecessarily annoying move (given that there are equally effective solutions that would not break production systems) on the part of a well-established ecosystem such as Bitnami. As software developers and software consumers, I think we have reached a tacit agreement that, thankfully, we all tend to honor:

• Creating new stuff: great.
• Archiving functioning software: it's okay.
• Stopping security updates: not ideal, but understandable.
• Actively breaking perfectly functioning systems: that's a no-go.

And doing so during a short period of the summer time... That's tough. I hope the bitnami team reconsiders their strategy.

[cmcga1125]

Hey @wjimenez5271
Yeah, I can spare some Zoom time today or tomorrow. Looks like your PST, I'm in EST - feel free to shoot me an email (I think you can get that information through GH? )

[james-mchugh]

As a long time Bitnami user, while the change is frustrating, the approach makes sense when you stop and think about it.

While it is disruptive, it's really not that bad. The switch to bitnamilegacy from bitnami is a nearly drop in change. The tags and digests are exactly the same, so it's essentially just a find and replace across your impacted repos. The disruption is the point here. A hard switch forces users to react to this change.

Without this hard switch, users may continue to use the bitnami registry, ignorant to these important changes. For users who rely on images that are continuously updated, the updates will just quietly stop. This may be difficult to notice at first, as the images would still be able to be pulled without issue. Forcing a migration to bitnamilegacy forces users to take action to deal with these changes, which will be needed since Bitnami will no longer be providing built artifacts.

This issue was posted 2 days ago (10 days before the targeted switch), but the initial notice for this was made over a month ago. That being said, I think we can all agree the timeline was too short. However, the disruption was arguably necessary to force users to react to the changes Bitnami is making. The alternative is to risk users not being made aware of these big changes until far after they've happened.

[wjimenez5271]

@cruizba I'm not sure what you mean by "new and old community images". Bitnami's source code for it's Debian based images is on Github: https://github.com/bitnami/containers, and the helm charts: https://github.com/bitnami/charts. That code continues to remain open under Apache 2. I think it would be helpful to take a look at those repos and take note of the difference between the source code and OCI registries provided by Docker Hub.