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 > > >
