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