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
gt;> 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
>> > >
aluation? 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 (fil
on't think
> > > > >> >> 'experimental' is
> > > > >> >> > the right word, but we should be clear around exactly what
> > > contract
> > > > >> we
> > > > >> >> are
> > > > >> >> > adhering to. Is it something people
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
>
ple 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 pro
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 qu
Since I accidentally injected some confusion I'll take it a step further.
We have doubly hermetically sealed environments. one docker file for the
Build and then it copies over to a minimalist image for the final
deployable image (using FROM and COPY --from ) .
Some of our tests are docker based
haha, sorry, I mean I agree with Don
On Tue, Mar 5, 2019 at 9:37 AM Charles Allen wrote:
> I agree with Gian on this sentiment.
>
> On Tue, Feb 19, 2019 at 7:47 AM Don Bowman wrote:
>
>> On Mon, 18 Feb 2019 at 19:14, Gaurav Bhatnagar
>> wrote:
>>
>> > I have been thinking if automated scripts
I agree with Gian on this sentiment.
On Tue, Feb 19, 2019 at 7:47 AM Don Bowman wrote:
> On Mon, 18 Feb 2019 at 19:14, Gaurav Bhatnagar wrote:
>
> > I have been thinking if automated scripts can be provided to end users in
> > Druid for "Additional Dependencies" for user initiated installation
ny 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
>> >> appropri
On Mon, 18 Feb 2019 at 19:14, Gaurav Bhatnagar wrote:
> I have been thinking if automated scripts can be provided to end users in
> Druid for "Additional Dependencies" for user initiated installation and
> configuration of optional dependencies to avoid licensing issues. Later
> these scripts can
le 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 guarant
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
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
>
arantees 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 ima
h. (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
then 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 >
> > wrote:
> >
> > > This is purely a packaging exercise. I don't see a reason to
> This is purely a packaging exercise. I don't see a reason to mark this as
> > experimental.
> >
> > Rajiv.
> >
> > From: Dylan Wylie
> > Sent: Friday, February 8, 2019 6:08:47 AM
> > To: dev@druid.apache.org
> >
nality and
interface adherence.
On Fri, Feb 8, 2019 at 7:14 AM Rajiv Mordani
wrote:
> This is purely a packaging exercise. I don't see a reason to mark this as
> experimental.
>
> Rajiv.
>
> From: Dylan Wylie
> Sent: Friday, February 8, 201
This is purely a packaging exercise. I don't see a reason to mark this as
experimental.
Rajiv.
From: Dylan Wylie
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 tick
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
Now that https://github.com/apache/incubator-druid/pull/6896 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
23 matches
Mail list logo
