potiuk commented on pull request #9652:
URL: https://github.com/apache/airflow/pull/9652#issuecomment-654157460
We are not taking more responsibility. We are making sure that we can
reproducibly rebuild those images and have control over it by the community.
Those two are different things.
See the
https://lists.apache.org/thread.html/r0d0f6f5b3880984f616d703f2abcdef98ac13a070c4550140dcfcacf%40%3Cdev.airflow.apache.org%3E
thread where I explained my reasoning and worries.
This change is really for making sure we have control over those images and
that the users of those images have trackable origin of the images (in this
solution it is trackable down to the commit). If the original image/library
changes, we can migrate to use the new one.
It's not a big issue In most cases for "dev" dependencies - we would maybe
touch it once a year (or when there is a concrete need to upgrade). So I just
added it for consistency.
But it's a different story for the "runtime" dependencies in the helm chart.
I believe that when we release the helm chart to our users, it is already our
responsibility to make sure this image is patched with latest security fixes
from "official" sources. Simply because by releasing those, we are suggesting
our users to use those images - just by providing them officially released helm
chart. I'd complain as a user if someone released a chart for production use
and told me to use it when at the moment of release latest available patches
are not applied. I think it's simply a consequence of releasing a
production-ready chart to our users and the responsibility for that is already
on us. As a PMC, this is responsibility I take when I do "+1" for such release.
I feel this is my responsibility as well, because as far as I know it has not
been (yet) in any way standardized by ASF. I started a thread here:
https://lists.apache.org/thread.html/rf2af2a95e7687fe94ede23fe9df388f784c8231a5968b109f677cbe8%40%3Cbuilds.apache.org%3E
but there are different approaches different projects do it seems. So we have
a freedom of deciding how we are going to approach it ourselves.
Again - this chart is intended for production use, so IMHO - with every
"official release" we should at the very least rebuild those images using the
latest version of the base images (containing latest security patches) and the
latest version of the "tools" we are releasing (for example pgbouncer).
Obviously - we cannot be responsible to upgrade those in-between releases, but
"official" release by the community simply should not use an unpatched based
image version as dependency - especially that it is easy to do.
By having a simple way of rebuilding the images by anyone and publishing
them in our registry, we do not "increase" our responsibility - the
responsibility is already there. We are increasing community control over it
instead.
I think this is not at all difficult, burdensome and problematic to use this
approach. It's easy to follow, reproducible and IMHO does not oblige us to
anything more than needed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
