www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Controlling the images used for the builds/releases
Date Tue, 23 Jun 2020 21:42:08 GMT
On Tue, Jun 23, 2020 at 2:26 AM Jarek Potiuk <Jarek.Potiuk@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/>

Mime
View raw message