metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [Discuss] Direction of metron-docker
Date Tue, 07 Feb 2017 18:53:17 GMT
​Is having a goal of replacing Vagrant/Virtualbox for Docker in "Quick Dev"
and "Full Dev" mutually exclusive of the goals you outlined above?  We
could have both, no?  I am unsure if you are objecting to this specific
goal or not.​

On Mon, Feb 6, 2017 at 1:03 PM, Ryan Merriman <merrimanr@gmail.com> wrote:

> From the README:
>
> "Metron Docker is a Docker Compose application that is intended for
> development and integration testing of Metron. Use this instead of Vagrant
> when:
>
> - You want an environment that can be built and spun up quickly
> - You need to frequently rebuild and restart services
> - You only need to test, troubleshoot or develop against a subset of
> services"
>
> The "Quick Dev" environment actually serves 2 purposes:  a development
> environment and an end-to-end testing environment.  This module was
> intended to supplement or provide an alternative to the development
> environment part of "Quick Dev", not the end-to-end testing part.  It does
> have "Docker" in the name of the module so I can see how that might suggest
> a fully supported deployment option.  It shouldn't be used for that though
> because it doesn't include Ambari or MPack and isn't a true representation
> of a production Metron cluster.
>
> What is the direction?  I could see this evolving into a collection of
> profiles or recipes.  Need to development a custom parser?  Spin up an
> application that only includes the Storm, Kafka and Zookeeper images.  Want
> to develop a custom Kibana dashboard?  Spin up Elasticsearch and Kibana
> images preloaded with data.  Maybe an analytics profile could be created
> that only includes the tools you need for that?  The application that
> exists now in metron-docker could be considered a "rest" profile or a
> collection of containers that support all the functions of the rest API.
> It's very general purpose and supports a lot of use cases so I considered
> it a good starting point.  It's very useful if you're developing a UI and
> have limited knowledge of Ambari or big data platform services.  That was
> the initial motivation.
>
> I think you should view this as more of a toolbox and not a turnkey
> installation solution.  Maintaining and building development environments
> is something Docker is a really good fit for and I have found this works
> much better than our Ansible/Vagrant environment.  It's really fast and
> stays up all the time.
>
> But it's completely optional.  Use it if you think it will help you.  Or
> don't if "Quick Dev" is good enough and you've figured out how to tune it
> so that it's not completely unusable.  If everybody thinks it's confusing
> and no one uses it then we can take it out and I'll just go back to
> maintaining it privately.  But then I would miss out on Kyle's awesome
> contribution :)
>
> Ryan
>
> On Mon, Feb 6, 2017 at 10:12 AM, Nick Allen <nick@nickallen.org> wrote:
>
> > So what is the direction then, Ryan?  Can you describe what this is
> > supposed to be used for?
> >
> > I had thought people wanted this to replace the existing Vagrant-based
> > "Quick Dev"?  But apparently this is the assumption that you think I am
> > wrong on.
> >
> >
> >
> > On Mon, Feb 6, 2017 at 10:46 AM, Ryan Merriman <merrimanr@gmail.com>
> > wrote:
> >
> > > I agree with everything Kyle said and I think some of Nick's
> assumptions
> > > are false.  I don't see this a third deployment option.
> > >
> > > I can understand people not wanting to maintain another deployment path
> > > with Metron already being as big as it is.  Ensuring that you've tested
> > and
> > > updated all the appropriate components is already tedious.  But in the
> > case
> > > of this module, is it something that needs to updated anytime someone
> > makes
> > > a deployment related change?  I don't think so and I've never had that
> > > expectation.  The build won't fail and nothing from this project is
> ever
> > > deployed or shipped.  For me, maintaining this tool as needed is good
> > > enough.  What happens if a change is introduced that breaks
> something?  I
> > > discover it as I'm using the tool, fix it, contribute it back and move
> > on.
> > > No big deal.  I had been maintaining this privately for a while before
> > the
> > > PR was submitted and the work to keep it current with master was pretty
> > > minimal.  Does that mean it should live somewhere else besides the
> master
> > > branch in Metron?  I'm not sure what the answer is but there should be
> a
> > > way to share and collaborate with the community on tools like this that
> > > aren't necessarily deployed to production.  Kyle's contribution is
> > valuable
> > > and something I would definitely use.
> > >
> > > Ryan
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message