> > 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). > > > 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/>
