potiuk edited a comment 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 avoid.
   
   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]


Reply via email to