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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 > > > > > >
