It's not an anti-Ansible sentiment, it's more of an anti-using-Ansible-as-a-general-purpose-installer sentiment. Ansible is fantastic in a constrained environment where the OS, Python versions, and Ansible versions are known a priori and won't change without the Ansible maintainer's knowledge. Ambari is WAY harder to use at first, but basically, we're trading more effort up front for a (hopefully) lower barrier to entry and less support burden going forward.
-D... On Wed, Apr 26, 2017 at 1:16 PM, Otto Fowler <ottobackwa...@gmail.com> wrote: > I know there is a lot of anti-ansible sentiment. But having gone > spelunking through the MPack scripts and the metron.spec to more -777 let > me just say I missed ansible’s flexibility, and documentation. > > > On April 26, 2017 at 12:12:08, Nick Allen (n...@nickallen.org) wrote: > > > 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 > > > > > > > > > > > >
