[
https://issues.apache.org/jira/browse/COMDEV-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469516#comment-17469516
]
Jarek Potiuk edited comment on COMDEV-382 at 1/5/22, 7:46 PM:
--------------------------------------------------------------
Not much. I have not seen much of an interest or feedback despite following few
times, and there were other pressing/urgent things, so I let it "rot" literally.
We continue to release our [Helm
Chart|https://airflow.apache.org/docs/helm-chart/stable/installing-helm-chart-from-sources.html]
(as sources) that you can use to install
[Airflow|https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-sources.html]
using our reference Docker image released using Apache's DockerHub account (as
convenience artifact) -
[https://hub.docker.com/layers/132472132/apache/airflow] and provide
Dockerfile (whcih is released together with Airflow in "source" package) that
our users can use to customize their images (our reference image necessariy
contains only small subset of possible integrations as we have more than 70
"providers" in Airflow) - using our
[documentation|https://airflow.apache.org/docs/docker-stack/build.html]
I think it does not seem to bother anyone else but me, so for me the state is
literally "status quo".
I beleive there is no written policy on the installation vs. using images (or
at least I have not seen any). The "compiled" package (as I explained in my
proposal) does not really apply to docker image - simply because at the time
the policy was created, distribution via mechanism like Docker image was not a
thing. But I would love to clarify and modernize the policy as long as there is
at least a slight sign that it bothers someone in the organization :). So far I
have not really seen an interest in clarifying it.
Re Images vs. installing sounds like an odd "approach" indeed. In our case, we
are installing probably quite a lot of things which of various licences
(likely including GPL) by the mere "apt get" inctruction in the Dockerfile and
the "approach" (I would not dare to name it "policy") that you were told would
make it virtually impossible to build any image. Not sure who is behind "being
told" but whoever proposed that, should realise that "hard" introducing of that
policy will virtually make it impossible to provide any image by any PMC.
Example: I just looked it up and the first renown Apache project I checked
(Flink - randomly) has an image where OpenJDK is definitely downloaded and not
used from image
[https://hub.docker.com/layers/132472132/apache/flink/latest/images/sha256-3c2ccf6cdb35df7e0f9e94fa2e17e2c1777639d4c80148abb082cf7a6ac0c2ea?context=repo]
. It is downloaded from here:
[https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u302-b08/OpenJDK8U-jre_x64_linux_8u302b08.tar.gz]
. So I am pretty sure that the "do not install" "approach" it's not what
really happens.
Maybe that someone could tell here where it is coming from and join the
discussion ? I am happy to reopen that discussion and put forward my proposal,
but I would love to have someone who I could discuss it with, because so far
there was no-one that I am aware of who could say authoritatively "this is our
policy for images" when I asked/made a proposal, similarly there was no-one to
say "this is wrong what you are doing".
But I am totally open to discuss it, just need to have someone to discuss it
with. Maybe there are few other people who would like to team up and we could
together agree and puth forth the proposal officially? I'd love to do it
together with others who are equally as I bothered by the lack of clear
guidelines and outdated definitions in this matter.
was (Author: higrys):
Not much. I have not seen much of an interest or feedback despite following few
times, and there were other pressing/urgent things, so I let it "rot" literally.
We continue to release our [Helm
Chart|https://airflow.apache.org/docs/helm-chart/stable/installing-helm-chart-from-sources.html]
(as sources) that you can use to install
[Airflow|https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-sources.html]
using our reference Docker image released using Apache's DockerHub account (as
convenience artifact) -
[https://hub.docker.com/layers/132472132/apache/airflow] and provide
Dockerfile (whcih is released together with Airflow in "source" package) that
our users can use to customize their images (our reference image necessariy
contains only small subset of possible integrations as we have more than 70
"providers" in Airflow) - using our
[documentation|https://airflow.apache.org/docs/docker-stack/build.html]
I think it does not seem to bother anyone else but me, so for me the state is
literally "status quo".
I beleive there is no written policy on the installation vs. using images (or
at least I have not seen any). The "compiled" package (as I explained in my
proposal) does not really apply to docker image - simply because at the time
the policy was created, distribution via mechanism like Docker image was not a
thing. But I would love to clarify and modernize the policy as long as there is
at least a slight sign that it bothers someone in the organization :). So far I
have not really seen an interest in clarifying it.
Re Images vs. installin sounds like an odd "approach" indeed. In our case, we
are installing probably quite a lot of things which of various licences
(likely including GPL) by the mere "apt get" inctruction in the Dockerfile and
the "approach" (I would not dare to name it "policy") that you were told would
make it virtually impossible to build any image. Not sure who is behind "being
told" but whoever proposed that, should realise that "hard" introducing of that
policy will virtually make it impossible to provide any image by any PMC.
Example: I just looked it up and the first renown Apache project I checked
(Flink - randomly) has an image where OpenJDK is definitely downloaded and not
used from image
[https://hub.docker.com/layers/132472132/apache/flink/latest/images/sha256-3c2ccf6cdb35df7e0f9e94fa2e17e2c1777639d4c80148abb082cf7a6ac0c2ea?context=repo]
. It is downloaded from here:
[https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u302-b08/OpenJDK8U-jre_x64_linux_8u302b08.tar.gz]
. So I am pretty sure that the "do not install" "approach" it's not what
really happens.
Maybe that someone could tell here where it is coming from and join the
discussion ? I am happy to reopen that discussion and put forward my proposal,
but I would love to have someone who I could discuss it with, because so far
there was no-one that I am aware of who could say authoritatively "this is our
policy for images" when I asked/made a proposal, similarly there was no-one to
say "this is wrong what you are doing".
But I am totally open to discuss it, just need to have someone to discuss it
with. Maybe there are few other people who would like to team up and we could
together agree and puth forth the proposal officially? I'd love to do it
together with others who are equally as I bothered by the lack of clear
guidelines and outdated definitions in this matter.
> Prepare a proposal for Policy for Helm Charts and Container images ASF
> policies
> -------------------------------------------------------------------------------
>
> Key: COMDEV-382
> URL: https://issues.apache.org/jira/browse/COMDEV-382
> Project: Community Development
> Issue Type: Proposal
> Components: Comdev
> Reporter: Jarek Potiuk
> Priority: Major
>
> There is a discussion started in the comdev mailing list about release
> policies related to release "Convenience Packages" relevant for the modern
> way of releasing "cloud" projects - Container Images and Helm Charts. Seems
> that the current policies are not fully answering the questions of projects
> trying to release those, and there is likely a need to provide an ASF
> "approved" way how to make the images and Helm Charts available to users.
> [https://lists.apache.org/thread.html/rcb608739206d788785081073a0deb417ffa9981634975fc5525dc769%40%3Cdev.community.apache.org%3E]
>
>
> The issue is created to keep track on the progress of the proposal that
> should become an official policy for the ASF projects on how to approach this.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
