Quick Dev - Atlas Images

[Nick Allen <ni...@nickallen.org>]

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

Re: Quick Dev - Atlas Images

[David Lyle <dl...@gmail.com>]

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 <ot...@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 (nick@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 <ot...@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 (nick@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 <dl...@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 <ni...@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
> > > >
> > >
> >
> >
>

Re: Quick Dev - Atlas Images

[Otto Fowler <ot...@gmail.com>]

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 (nick@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 <ot...@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 (nick@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 <dl...@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 <ni...@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
> > >
> >
>
>

Re: Quick Dev - Atlas Images

[Nick Allen <ni...@nickallen.org>]

> 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 <ot...@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 (nick@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 <dl...@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 <ni...@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
> > >
> >
>
>

Re: Quick Dev - Atlas Images

[Otto Fowler <ot...@gmail.com>]

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 (nick@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 <dl...@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 <ni...@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
> >
>

Re: Quick Dev - Atlas Images

[Michael Miklavcic <mi...@gmail.com>]

I may have missed a discuss thread on this, but it looks like we are no
longer using -SNAPSHOT in our current dev master
https://github.com/apache/incubator-metron/blob/master/pom.xml#L19

On Tue, Apr 25, 2017 at 12:34 PM, Nick Allen <ni...@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 <dl...@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 <ni...@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
> > >
> >
>

Re: Quick Dev - Atlas Images

[Nick Allen <ni...@nickallen.org>]

>>  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 <dl...@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 <ni...@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
> >
>

Re: Quick Dev - Atlas Images

[David Lyle <dl...@gmail.com>]

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 <ni...@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
>