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

question: purpose of "Daily automatic update" #131

Open
ardentperf opened this issue Dec 27, 2024 · 1 comment
Open

question: purpose of "Daily automatic update" #131

ardentperf opened this issue Dec 27, 2024 · 1 comment

Comments

@ardentperf
Copy link

ardentperf commented Dec 27, 2024

I noticed that the IMAGE_RELEASE_VERSION seems to be automatically incremented every day. at first i thought there weren't changes in most of these daily updates, but after looking closer i realized they do include changes.

I took a closer look at Debian 12 bookworm releases 23 to 27 and found the following:

  • 27 and 26: only change is "POSTGRES_IMAGE_LAST_UPDATED" timestamp
  • 25 and 23: only change is version bump in boto3 & botocore dependencies in requirements.txt
  • 24: only change is version bump in urllib3 dependency in requirements.txt

i don't quite understand why we need new releases just to update the "POSTGRES_IMAGE_LAST_UPDATED" timestamp

and do i understand correctly that the whole python thing is for building Barman Cloud, which isn't even our optimal solution (ie. CNPG-I will hopefully get rid of this whole thing and let us move back to using CNPG deb packages for barman)?

it seems to me like we're basically doing a rolling release of barman where we update all the python deps every day? and the boto libs seem to especially stand out for having frequent updates, driving version number bumps of the package basically because barman keeps getting rebuilt with updated dependencies

do we really need - or even want - to be automatically rebuilding our production barman builds every day to bump dependency versions? maybe we do, i think there might be an argument for it.

but another possible approach would be to do the dependency updates on a test branch (for catching problems early) but do production updates less frequently (eg. when there is an actual new barman release, or a security fix in a dependency).

As a downstream consumer managing a fleet of CNPG deployments, personally i'd favor a bit less frequent version updates in the production releases rather than automatically pulling every single boto lib update.

@gbartolini
Copy link
Contributor

gbartolini commented Jan 2, 2025

Completely agree with you. Based on your proposal for container images, we are revisiting the whole building process - I will open a new ticket for this.

PR #127 reduces the frequency to once a week.

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

No branches or pull requests

2 participants