-
Notifications
You must be signed in to change notification settings - Fork 85
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
base: main
Are you sure you want to change the base?
[WIP] chore(deps): bump bitnami-common and bitnami-postgresql versions #232
Conversation
5dfab2a
to
0e1b016
Compare
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) |
@ChrisJBurns no worries, I would like to get the ability to set the |
0e1b016
to
2ac2e62
Compare
@ChrisJBurns The base helm install is working on minikube, can you authorize the workflow that is awaiting approval? |
@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 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. |
@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. |
2ac2e62
to
3104529
Compare
@ChrisJBurns Do you think this would be an appropriate topic for me to bring up on the SIG Framework call? |
@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? |
@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) |
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! |
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! |
I am still working on this, I have just been temporarily moved to another project priority. |
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! |
Reopening as @coreydaley is still working on it |
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! |
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! |
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! |
@ChrisJBurns I am back to being able to work on this again, thanks for keeping it open for me! |
3104529
to
77afae4
Compare
Signed-off-by: Corey Daley <cdaley@redhat.com>
77afae4
to
2d6ba31
Compare
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! |
@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 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?
|
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 |
@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. |
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! |
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.yaml
according to semver.values.yaml
and added to the README.md. The helm-docs utility can be used to generate the necessary content. Usehelm-docs --dry-run
to preview the content.ct lint
command.