On Tue, Jun 23, 2020 at 2:26 AM Jarek Potiuk <jarek.pot...@polidea.com>
wrote:
My understanding the bigger problem is the license of the dependency
(and
their dependencies) rather than the official/unofficial status. For
Apache
Yetus' test-patch functionality, we defaulted all of our plugins to
off
because we couldn't depend upon GPL'd binaries being available or
giving
the impression that they were required. By doing so, it put the onus
on
the user to specifically enable features that depends upon GPL'd
functionality. It also pretty much nukes any idea of being user
friendly.
:(
Indeed - Licensing is important, especially for source code
redistribution.
We used to have some GPL-install-on-your-own-if-you-want in the past but
those dependencies are gone already.
2) If it's not - how do we determine which images are "officially
maintained".
Keep in mind that Docker themselves brand their images as
'official' when they actually come from Docker instead of the
organizations
that own that particular piece of software. It just adds to the
complexity.
Not really. We actually plan to make our own Apache Airflow Docker
image as
official one. Docker has very clear guidelines on how to make images
"official" and it https://docs.docker.com/docker-hub/official_images/
and
there is quite a long iist of those:
https://github.com/docker-library/official-images/tree/master/library -
most of them maintained by the "authirs" of the image. Docker has a
dedicated team that reviews, checks those images and they encourage that
the "authors" maintain them. Quote from Docker's docs: "While it is
preferable to have upstream software authors maintaining their
corresponding Official Images, this is not a strict requirement."
3) If yes - how do we put the boundary - when image is acceptable?
Are
there any criteria we can use or/ constraints we can put on the
licences/organizations releasing the images we want to make
dependencies
for released code of ours?
License means everything.
For software distribution - true. It is the "blocker". But I think my
question goes a bit beyond that - i.e. whether it's ok to
encourage/depend
on the work maintained by other organizations than Apache if they are
not
"official". My take is that it's likely OK to depend on that providing
that
there is a kind of statement from those organizations that they
maintain it.
An example risk I see:
Airflow users depend heavily on helm chart to install Airflow - what
happens if the community agrees to implement something that the
organization does not want to implement (for whatever reason).
FWIW: every corporation I ever worked at would commission a
BlackDuck/Palamida
report of a total software scans for its products. There was some
amount of: "this
ASF project pulls a dependency FOO (non ASF) that is declared to be
licensed under
the license X but it actually isn't -- here's why..."
We trust our upstream dependencies, but I don't think we can verify
them as a foundation.
Hence we keep relying on that feedback coming from corporate sides.
Thanks,
Roman.
4) If some images are not acceptable, shoud we bring them in and
release
them in a community-managed registry?
For the Apache Yetus docker image, we're including everything
that
the project supports. *shrugs*
Yeah. That's perfectly OK in many cases. Our docker image is also
self-containing. However, Airflow is a bit special here. Airflow is an
orchestrator which means that it can talk to many different services. We
have 58(!) "providers" - basically external services we can talk to. And
many of those services require many dependencies - for example Cassandra
(for production installation) requires cython-compiled driver (for
performance) and it takes 10 minutes to build it. The smaller the
images -
the better - therefore the images we release contain the most "popular"
providers rather than all of them, but the user can build their own
image
from the sources if they want and add those extra dependencies they
need.
Another problem is - helm chart uses - by definition - a collection of
images - so we will always have some images that helm chart depends on
(pgbouncer is a good example). So it cannot be really self-contained. We
need to have dependencies, but the question is about "who controls them
:)"
J.
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
