I think people definitely do want it, but since the connector is GPL and GPL is Category X, we need to dot our i's and cross our t's when considering whether / how to include it. Removing it pending the completion of that discussion is definitely the path of least resistance.
On Mon, Feb 18, 2019 at 1:59 PM Don Bowman <d...@agilicus.com> wrote: > i can just remove the mysql, the postgres works, i was just assuming folks > wanted it. > > > On Mon, 18 Feb 2019 at 16:58, Gian Merlino <g...@apache.org> wrote: > > > A discussion is progressing on > > https://issues.apache.org/jira/browse/LEGAL-437. It doesn't seem to have > > got anywhere firm yet. > > > > On Fri, Feb 8, 2019 at 12:23 PM Gian Merlino <g...@apache.org> wrote: > > > > > I don't think anything is strictly needed from you at this point, but > > > things happen when people drive them, and participation in that effort > > > would help make sure it gets done. I think at this point the tasks on > our > > > end are watching LEGAL-437 for advice (or making it moot by removing > the > > > MySQL jar), asking Infra to set up automated builds once that is sorted > > > out, and building some kind of consensus around how we'll label and > > promote > > > the Docker images. > > > > > > On Fri, Feb 8, 2019 at 12:13 PM Don Bowman <d...@agilicus.com> wrote: > > > > > >> i'd be fine w/ removing the mysql, i'm using postgresql for the > > metadata. > > >> if this is the case we should consider relfecting postgres as the > > default > > >> metadata in the docs. > > >> however, i think this is mere aggregation under the gpl license, and > the > > >> docker image tends to have other (e.g. bash) gpl code. druid's start > > >> scripts are all bash-specific as an example. > > >> > > >> I'm not clear if anything further is needed of me, i'm hoping to get > an > > >> automated build going into dockerhub, and tagged w/ each release. i > > think > > >> this will help adoption. > > >> > > >> > > >> > > >> On Fri, 8 Feb 2019 at 14:22, Gian Merlino <g...@apache.org> wrote: > > >> > > >> > First off thanks a lot for your work here Don!! > > >> > > > >> > I really do think, though, that we need to be careful about the > > >> inclusion > > >> > of the MySQL connector jar. ASF legal has been clear in the past > that > > >> ASF > > >> > projects should not distribute it as part of binary convenience > > >> releases: > > >> > https://issues.apache.org/jira/browse/LEGAL-200. I think having the > > >> > Dockerfile in the repo is probably fine: in that case we are not > > >> > distributing the jar itself, just, essentially, a pointer to how to > > >> > download it. But if we start offering a prebuilt Docker image, it is > > >> less > > >> > clear to me if that is fine or not. In the interests of resolving > this > > >> > question one way or the other, I opened a question asking about this > > >> > specific situation: https://issues.apache.org/jira/browse/LEGAL-437 > . > > >> > > > >> > About Dylan's questions: my feeling is that we should go ahead and > > >> enable > > >> > automated pushes to Docker Hub, and provide some appropriate > language > > >> > around what people should expect out of it. I don't think > > >> 'experimental' is > > >> > the right word, but we should be clear around exactly what contract > we > > >> are > > >> > adhering to. Is it something people can expect to be published with > > each > > >> > release? Is it something that we are going to build and test as part > > of > > >> the > > >> > release process, or are we going to publish it via automation > without > > >> any > > >> > testing? Is it something we expect people to use in production, or > > >> > something we only expect people to use for evaluation? If it is > > >> something > > >> > we expect people to use in production, do we expect them to use it > in > > >> any > > >> > particular way? Will we be guaranteeing certain things (file layout, > > >> etc) > > >> > that provide a stable interface for people to build derived images > > from? > > >> > > > >> > The path of least resistance to answering these questions is to say > > that > > >> > the Docker image is provided in the hopes that it is useful, but > that > > >> it is > > >> > done via an automated build, without any pre-release testing, and > > >> without > > >> > any particular guarantees about the 'interface' it provides. If this > > is > > >> the > > >> > case then I would suggest putting it up on Docker Hub with an > > >> appropriate > > >> > disclaimer and not promoting it too much. (We might very well end up > > >> > pushing images every once in a while that don't work right, and it > > would > > >> > reflect poorly on the project to have those be prominently > linked-to.) > > >> It > > >> > becomes easier to strengthen these guarantees if we add an automated > > >> test > > >> > suite that we can run before releases which verifies functionality > and > > >> > interface adherence. > > >> > > > >> > On Fri, Feb 8, 2019 at 7:14 AM Rajiv Mordani > > >> <rmord...@vmware.com.invalid> > > >> > wrote: > > >> > > > >> > > This is purely a packaging exercise. I don't see a reason to mark > > >> this as > > >> > > experimental. > > >> > > > > >> > > Rajiv. > > >> > > ________________________________ > > >> > > From: Dylan Wylie <dylanwy...@apache.org> > > >> > > Sent: Friday, February 8, 2019 6:08:47 AM > > >> > > To: dev@druid.apache.org > > >> > > Subject: Re: docker build > > >> > > > > >> > > I believe all we have to do is submit a ticket to Apache's > > >> Infrastructure > > >> > > team and then we'll have some automatic process that'll > > automatically > > >> > > update docker-hub with images relating to each release. > > >> > > > > >> > > I guess there's two open questions I think we should reach a > > >> consensus on > > >> > > (others feel free to add more!). > > >> > > > > >> > > - Are we as a community happy to "support" an additional release > > >> > artefact? > > >> > > I'm happy to try to incorporate this into my employer's testing > > >> > > infrastructure to help catch any regressions on future releases > but > > >> > that's > > >> > > just one data point on each release. > > >> > > > > >> > > - Along the same vein, do we follow the same process as we do with > > new > > >> > > features and mark this as experimental for some time? > > >> > > > > >> > > On Fri, 8 Feb 2019 at 13:25, Don Bowman <d...@agilicus.com> wrote: > > >> > > > > >> > > > Now that > > >> > > > > >> > > > >> > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-druid%2Fpull%2F6896&data=02%7C01%7Crmordani%40vmware.com%7C942b2af1dfb740fcbed308d68dcef937%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636852317419449405&sdata=EXigZIBkKiatM0rEgyQRoxA9ER8u8amiAfPN0MghzjE%3D&reserved=0 > > >> > > is merged > > >> > > > (thank you!) > > >> > > > > > >> > > > who can get this set to build into Dockerhub? Presumably > > >> automatically > > >> > > on a > > >> > > > 'tag' of the repo. > > >> > > > > > >> > > > Once that is done it is much more convenient for folks to use > this > > >> > tool. > > >> > > > > > >> > > > --don > > >> > > > > > >> > > > > >> > > > >> > > > > > >
