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 > > > > > >
