Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] chore(deps): bump bitnami-common and bitnami-postgresql versions #232

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

coreydaley
Copy link
Contributor

@coreydaley coreydaley commented Nov 4, 2024

Description of the change

The bitnami-common and bitnami-postgresql dependencies are pretty old and could use an update to provide expanded functionality for the Backstage Helm Chart. This update bumps both packages to their current latest versions

Existing or Associated Issue(s)

Fixes #191

Additional Information

Checklist

  • Chart version bumped in Chart.yaml according to semver.
  • Variables are documented in the values.yaml and added to the README.md. The helm-docs utility can be used to generate the necessary content. Use helm-docs --dry-run to preview the content.
  • JSON Schema generated.
  • List tests pass for Chart using the Chart Testing tool and the ct lint command.

@coreydaley coreydaley requested a review from a team as a code owner November 4, 2024 16:40
@coreydaley coreydaley force-pushed the 2024-11-04-update-chart-dependencies branch 2 times, most recently from 5dfab2a to 0e1b016 Compare November 4, 2024 16:47
@ChrisJBurns
Copy link
Contributor

Thanks @coreydaley, beat me to it (although I was taking a while), for reference, this was the issue raised to bump the deps #191.

Although I think we'll need a major version update to the Backstage Helm Chart as we are updating the Postgres Sub-Chart by 4 major versions. I'm wondering what we should do around testing? We don't want to cause problems for those who are on Postgres 12 (and haven't overridden the DB image chart values for it)

@coreydaley
Copy link
Contributor Author

coreydaley commented Nov 4, 2024

@ChrisJBurns no worries, I would like to get the ability to set the global.compatibility.openshift.adaptSecurityContext option which is in the newer versions.

@coreydaley coreydaley force-pushed the 2024-11-04-update-chart-dependencies branch from 0e1b016 to 2ac2e62 Compare November 4, 2024 18:45
@coreydaley
Copy link
Contributor Author

@ChrisJBurns The base helm install is working on minikube, can you authorize the workflow that is awaiting approval?

@coreydaley
Copy link
Contributor Author

@ChrisJBurns As far as the PostgreSQL getting upgraded, I think that documentation/release notes/education is the way to go, hopefully people will see that it is a major version bump and read the docs/notes. The upgrade from any major-to-major PostgreSQL version looks to be a manual process, probably using the pgupgrade command.

We could also do some manual testing and see if a helm rollback to the previous chart version would let a user recover from doing an upgrade and continue to work while they figure out why it failed, which will be because of the PostgreSQL difference. Thoughts?

An alternative (maybe) would be to update this chart to bake in the version of PostgreSQL that is currently supported and people can upgrade if they want to? Would definitely have to be some manual verification of if that would work, but it seems like it would. If they have overridden it to a different version that should still work, and if not, the version would still be what they had before.

@ChrisJBurns
Copy link
Contributor

@coreydaley Will approve the PR just to kick off the workflow, we can have a think in the meantime of the best way of going about the upgrade is and communicating that to users.

@coreydaley
Copy link
Contributor Author

@ChrisJBurns Do you think this would be an appropriate topic for me to bring up on the SIG Framework call?

@ChrisJBurns
Copy link
Contributor

@coreydaley Which SIG Framework are you referring to? Having a think, I'm wondering if we want to implement the incremental major bumps instead of jump from 12 to 16? This somewhat gives users the opportunity to minimise the amount of changes to the underlying chart per release?

@coreydaley
Copy link
Contributor Author

@ChrisJBurns Sorry, this one: https://github.com/backstage/community/tree/main/sigs/sig-framework

Let me do a bit of testing and see what kind of issues we can expect and I'll post back my results here (hopefully early this week)

Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

@github-actions github-actions bot added the stale label Nov 27, 2024
@coreydaley
Copy link
Contributor Author

I am still working on this, I have just been temporarily moved to another project priority.

@github-actions github-actions bot removed the stale label Dec 2, 2024
Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

@github-actions github-actions bot added the stale label Dec 10, 2024
@github-actions github-actions bot closed this Dec 16, 2024
@ChrisJBurns ChrisJBurns reopened this Dec 21, 2024
@ChrisJBurns
Copy link
Contributor

Reopening as @coreydaley is still working on it

@github-actions github-actions bot removed the stale label Dec 22, 2024
Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

Copy link

github-actions bot commented Jan 8, 2025

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

@github-actions github-actions bot added the stale label Jan 8, 2025
@ChrisJBurns ChrisJBurns removed the stale label Jan 9, 2025
Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

@coreydaley
Copy link
Contributor Author

@ChrisJBurns I am back to being able to work on this again, thanks for keeping it open for me!

@coreydaley coreydaley force-pushed the 2024-11-04-update-chart-dependencies branch from 3104529 to 77afae4 Compare January 23, 2025 15:07
Signed-off-by: Corey Daley <cdaley@redhat.com>
@coreydaley coreydaley force-pushed the 2024-11-04-update-chart-dependencies branch from 77afae4 to 2d6ba31 Compare January 23, 2025 15:11
Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

@github-actions github-actions bot added the stale label Jan 31, 2025
@coreydaley
Copy link
Contributor Author

@ChrisJBurns According to https://semver.org/, a MAJOR version bump denotes incompatible API changes, which in this case I would associate with having to manually update from PostgreSQL 15.x to PostgreSQL 16.x including at least one manual step of migrating the database. We could document this on the main README.md file. I see that you can also include a message in the NOTES.txt in the templates directory, but that only seems to show up after a helm install or helm update. Maybe we could add a NOTES.txt to the current helm chart with a warning that versions >= 3.x require manual steps when upgrading from 2.x and to check the instructions in the README.md?

The current chart could also use a small bump to the bitnami-common and bitnami/postgresql dependencies it looks like, which would give us a chance to add the NOTES.txt file and also a warning in the README.md about upgrading.

What do you think?

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

@github-actions github-actions bot removed the stale label Feb 4, 2025
@ChrisJBurns
Copy link
Contributor

ChrisJBurns commented Feb 8, 2025

Thanks for the above @coreydaley! Taking a step back for a moment, I'm wondering whether we should take on the full responsibility of managing the PostgreSQL dependency at this stage? Since this Helm Chart is primarily focused on installing Backstage, perhaps we should limit our scope to just that. The PostgreSQL deployment was originally included as a convenient way to install Backstage in one step, but maybe it’s best to clarify this in the documentation. Our official recommendation could be for users to deploy PostgreSQL externally, aligning with best practices and reducing potential maintenance burdens on our end. This approach would not only free us from supporting users with PostgreSQL-related issues but also empower users to manage their own database deployments independently.

What this means for the Postgres update, is that we just release a new major version of the Chart with the 12.x -> 16.x version jump. Happy to hear your thoughts @coreydaley @vinzscam @sabre1041 @tumido as I was (and in a way, still am) in two minds about this.

@sabre1041
Copy link
Contributor

@coreydaley @ChrisJBurns For any open source project, the getting started experience is one of the most important factors for adoption. For a production implementation of backstage, integrating with an externally managed instance of PostgreSQL is certainly highly recommended. However, for any user who is just getting started with Backstage, they are getting up to speed with quite a number of concepts and patterns. They will be less likely to take on an additional task to manage the lifecycle of the database as well as configuring the properties within Backstage.

The backend database, while essential, I would recommend that the database should continue to be maintained. This will also enable continued validation of the integration between both projects as they each independently evolve.

Copy link

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade Charts Dependencies
3 participants