> I think you can have vagrant use docker as a back end too right? I don't know about using Docker as a backend for Vagrant. I don't think Vagrant is our major sticking point. I think Ansible is the problem. We have a lot of deployment functionality still in Ansible. Much of that has been moved to Ambari which helps a ton, but we have a fair amount left AFAIK.
> If it is docker, then it is just the Dockerfiles. Agreed, the storage size would be lighter weight with Docker. But there are a lot of other comparisons to make when thinking about Docker too. Many of which I don't know the answers to right now. - Would Docker offer a more "production-like" environment? In that each component can run on isolated components? - Can we avoid some of the resource constraints that we currently have in running single-node Metron? - Can we avoid re-writing the entire deployment process? - How does the "time to start" compare for a "canned" release image as Dave suggested? On Tue, Apr 25, 2017 at 4:09 PM, Otto Fowler <ottobackwa...@gmail.com> wrote: > If it is docker, then it is just the Dockerfiles. > I think you can have vagrant use docker as a back end too right? > > > > On April 25, 2017 at 14:34:14, Nick Allen (n...@nickallen.org) wrote: > > >> I hadn't really reasoned about the notion of a "released" Quick Dev > image, > but I can see a lot of value in having a versioned sandbox type image- but > maybe not quick dev, maybe not even Vagrant? We could actually pre-package > everything needed and save some provisioning time on released versions. > > I really like the idea. I think it would be very beneficial to have a > single pre-packaged image for each release that users can download and > take > new features for a spin. > > If we do stick with Vagrant for this I think Atlas works just fine. Who > else is going to host a 5.1 GB image for us? :) Although I am very open to > alternative implementations of this idea. > > > >> I always thought of Quick Dev as a developer tool, so our obligation is > to make it work with the current master and any branches currently used by > devs. > > Would be interested to get other opinions on this. I am good with making > that assumption. Whatever the community agrees on for Quick Dev though, > we should document it as such. Right now, I think it would be reasonable > to assume that a user would download a release and expect to be able to > launch Quick Dev. > > > > > > > > > > On Mon, Apr 24, 2017 at 11:51 AM, David Lyle <dlyle65...@gmail.com> > wrote: > > > I think it's a really good idea. There is some complexity: > > > > a) Image releases do not map 1:1 with Metron releases and Atlas doesn't > > allow -SNAPSHOT in their release number scheme. That is, we'll have > > different versions of the image that work with a 0.4.1-SNAPSHOT Metron > and > > some released versions of Metron that won't require a new image (A guy's > > gotta believe). I think that can be easily worked around. > > > > b) If the Quick Dev image becomes one of our release artifacts, Atlas is > > likely the wrong place to host it. > > > > I always thought of Quick Dev as a developer tool, so our obligation is > to > > make it work with the current master and any branches currently used by > > devs. I hadn't really reasoned about the notion of a "released" Quick > Dev > > image, but I can see a lot of value in having a versioned sandbox type > > image- but maybe not quick dev, maybe not even Vagrant? We could > actually > > pre-package everything needed and save some provisioning time on > released > > versions. It'd just come up ready to go. I think, should we want one, we > > should release it as a convenience binary signed and hosted alongside > the > > other release artifacts. Meantime, we could keep the incremental > versions > > of Quick Dev in Atlas. > > > > Anyway, I think it's a really interesting notion. > > > > -D... > > > > > > On Mon, Apr 24, 2017 at 11:26 AM, Nick Allen <n...@nickallen.org> > wrote: > > > > > Right now, we have the images that get pushed to Atlas for Quick Dev > > > <https://atlas.hashicorp.com/metron/boxes/quick_dev> versioned > > > independently from the rest of Metron. We currently have versions > 0.1.0 > > > and 0.2.0. > > > > > > What happens when a user downloads an official release of Metron, like > > > 0.3.1, and attempts to run Quick Dev? I would assume that the code > would > > > download the latest image version, which we may have been updated > since > > the > > > release. This would cause it to fail for the release version. Am I > > wrong? > > > > > > If we had the Atlas images follow Metron's versioning scheme, would > this > > > solve the problem? Are there other cons of doing this? > > > > > > Thanks > > > > > > >
