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&amp;data=02%7C01%7Crmordani%40vmware.com%7C942b2af1dfb740fcbed308d68dcef937%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636852317419449405&amp;sdata=EXigZIBkKiatM0rEgyQRoxA9ER8u8amiAfPN0MghzjE%3D&amp;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
> >> > > >
> >> > >
> >> >
> >>
> >
>

Reply via email to