spilo
spilo copied to clipboard
zalando
CVE fixes needed
Hello,
when will be the next spilo release and will there be CVE fixes included? The current 3.0-p1 image has a lot of CVEs. Would it be possible to have a regular / monthly release with updated base image packages to reduce CVEs in the future?
Best
Fabian
Would it be possible to have a regular / monthly release
Yes, we should definitely work on this, unfortunately, the project has been abandoned for some months now. We are testing the current master branch state internally and if everything is fine, I hope to push the new release the next week (still without upgrading the Patroni version though)
Hi
what is the actual status? It would be really great to get an updated image (even without Patroni) asap.
Best Fabian
I have attempted to use the current master branch with the most recent postgres-operator release, but the postgres database cannot be connected to.
An issue has been created here: https://github.com/zalando/spilo/issues/923
Hello @hughcapet. Commenting you here
unfortunately, the project has been abandoned for some months now
So does that mean that no one from zalando is supporting spilo image atm?
The master branch is periodically updated and tested internally. The release cycle is unfortunately on hold now
Understood. Are we safe to ensure the self build image is working properly by running the test routine located in the tests folder?
Otherwise it would be nice to get some information about how you test that the image is working properly.
I think once that is clear it should be easy to create a pipeline which builds images from the master branch.
The test routine located in the tests folder indeed checks the main functionality blocks of Spilo (e.g. bootstrapping, in-place upgrades, cloning...). But then should definitely come testing of your specific deployment model (for example, internally we also test integration with the Operator). This sometimes reveals specific Spilo problems/bugs. And of course, given the amount of Spilo's external dependencies (e.g. PG extensions), many problems only appear during the actual usage by the end-users (that is why the so-called releases in the past were only made after we run the image built from the current master branch's state internally for some time). But again - knowing nothing is pinned, I can not guarantee that what we tested internally will have the same (or even similar) state to what I tag and build as a release later. IMO, the whole release model should be changed. Hopefully, it happens in the future :)