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