Re: Quick Dev
Created METRON-1239 <https://issues.apache.org/jira/browse/METRON-1239> to track this. On Fri, Oct 6, 2017 at 8:59 AM, Simon Elliston Ball < si...@simonellistonball.com> wrote: > I think the codelab build might be more Metron archeologist! > > +1 to a big old clearout, especially on the wiki. > > > On 6 Oct 2017, at 13:57, Nick Allen wrote: > > > > I doubt it has been run in a long, long time. It was originally created > > for some Meetups that we did early on in the project. Useful then, but > not > > any longer. It might have even predated Quick Dev. > > > > FYI - We have an opening for Metron Team Historian. Send a cover letter, > > CV and $150 application fee to me for consideration. :) > > > > > > > > > > > > On Fri, Oct 6, 2017 at 8:52 AM Justin Leet > wrote: > > > >> What is the point of that anyway? It just looks like full dev with no > >> skipTags? That seems like it should just be documented that you can run > >> with Vagrant with '--ansible-skip-tags'? We probably should document any > >> tags you might want to skip anyway. > >> > >> I'm pretty in favor of killing that. > >> > >> On Fri, Oct 6, 2017 at 8:46 AM, Nick Allen wrote: > >> > >>> The same case might be made for the Code Lab Platform > >>> `metron-deployment/vagrant/codelab-platform`? > >>> > >>> On Fri, Oct 6, 2017 at 8:44 AM Justin Leet > >> wrote: > >>> > >>>> Wiki updated. It now points to full dev and the link just says "Dev > >>>> Platform" > >>>> > >>>> On Fri, Oct 6, 2017 at 8:39 AM, Nick Allen > wrote: > >>>> > >>>>> +1 To killing Quick Dev and updating the Wiki. Quick Dev has been > >>> broken > >>>>> for eons. Simon's point about "profusion of installs" makes a lot of > >>>> sense > >>>>> too. > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < > >>>>> si...@simonellistonball.com> wrote: > >>>>> > >>>>>> +1 we see a lot of people struggling with the profusion of install > >>> and > >>>>> run > >>>>>> methods as it is, if we can reduce that surface area, life will be > >> a > >>>> lot > >>>>>> easier on the user list. > >>>>>> > >>>>>>> On 6 Oct 2017, at 13:28, zeo...@gmail.com > >>> wrote: > >>>>>>> > >>>>>>> I say we kill it and repoint the site. That will give us one > >> less > >>>>> thing > >>>>>> to > >>>>>>> upgrade to centos 7 as well. > >>>>>>> > >>>>>>> Jon > >>>>>>> > >>>>>>> On Fri, Oct 6, 2017, 08:27 Justin Leet > >>>> wrote: > >>>>>>> > >>>>>>>> So what are we going to do with Quick Dev? I'm pretty sure > >>>>> everybody's > >>>>>>>> been using full dev for awhile now (and quick dev is probably > >>> broken > >>>>>> since > >>>>>>>> I'm sure we haven't been regularly updating it). > >>>>>>>> > >>>>>>>> I just realized our website links to a wiki page that says to > >> use > >>>>> quick > >>>>>>>> dev. Given that quick dev is broken or behind or both, this is > >>>> going > >>>>>> to be > >>>>>>>> incredibly confusing and misleading to anyone wandering in. > >>>>>>>> > >>>>>>>> A short term fix is to just point that wiki page to full dev, so > >>> we > >>>>>> aren't > >>>>>>>> at least broken to anyone coming in. > >>>>>>>> > >>>>>>>> After that we should figure out what we're doing with quick and > >>> full > >>>>> dev > >>>>>>>> and take care of whatever needs to be done. > >>>>>>>> > >>>>>>>> Thoughts? > >>>>>>>> > >>>>>>>> Justin > >>>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Jon > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
Re: Quick Dev
I think the codelab build might be more Metron archeologist! +1 to a big old clearout, especially on the wiki. > On 6 Oct 2017, at 13:57, Nick Allen wrote: > > I doubt it has been run in a long, long time. It was originally created > for some Meetups that we did early on in the project. Useful then, but not > any longer. It might have even predated Quick Dev. > > FYI - We have an opening for Metron Team Historian. Send a cover letter, > CV and $150 application fee to me for consideration. :) > > > > > > On Fri, Oct 6, 2017 at 8:52 AM Justin Leet wrote: > >> What is the point of that anyway? It just looks like full dev with no >> skipTags? That seems like it should just be documented that you can run >> with Vagrant with '--ansible-skip-tags'? We probably should document any >> tags you might want to skip anyway. >> >> I'm pretty in favor of killing that. >> >> On Fri, Oct 6, 2017 at 8:46 AM, Nick Allen wrote: >> >>> The same case might be made for the Code Lab Platform >>> `metron-deployment/vagrant/codelab-platform`? >>> >>> On Fri, Oct 6, 2017 at 8:44 AM Justin Leet >> wrote: >>> >>>> Wiki updated. It now points to full dev and the link just says "Dev >>>> Platform" >>>> >>>> On Fri, Oct 6, 2017 at 8:39 AM, Nick Allen wrote: >>>> >>>>> +1 To killing Quick Dev and updating the Wiki. Quick Dev has been >>> broken >>>>> for eons. Simon's point about "profusion of installs" makes a lot of >>>> sense >>>>> too. >>>>> >>>>> >>>>> >>>>> On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < >>>>> si...@simonellistonball.com> wrote: >>>>> >>>>>> +1 we see a lot of people struggling with the profusion of install >>> and >>>>> run >>>>>> methods as it is, if we can reduce that surface area, life will be >> a >>>> lot >>>>>> easier on the user list. >>>>>> >>>>>>> On 6 Oct 2017, at 13:28, zeo...@gmail.com >>> wrote: >>>>>>> >>>>>>> I say we kill it and repoint the site. That will give us one >> less >>>>> thing >>>>>> to >>>>>>> upgrade to centos 7 as well. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On Fri, Oct 6, 2017, 08:27 Justin Leet >>>> wrote: >>>>>>> >>>>>>>> So what are we going to do with Quick Dev? I'm pretty sure >>>>> everybody's >>>>>>>> been using full dev for awhile now (and quick dev is probably >>> broken >>>>>> since >>>>>>>> I'm sure we haven't been regularly updating it). >>>>>>>> >>>>>>>> I just realized our website links to a wiki page that says to >> use >>>>> quick >>>>>>>> dev. Given that quick dev is broken or behind or both, this is >>>> going >>>>>> to be >>>>>>>> incredibly confusing and misleading to anyone wandering in. >>>>>>>> >>>>>>>> A short term fix is to just point that wiki page to full dev, so >>> we >>>>>> aren't >>>>>>>> at least broken to anyone coming in. >>>>>>>> >>>>>>>> After that we should figure out what we're doing with quick and >>> full >>>>> dev >>>>>>>> and take care of whatever needs to be done. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Justin >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Jon >>>>>> >>>>>> >>>>> >>>> >>> >>
Re: Quick Dev
I doubt it has been run in a long, long time. It was originally created for some Meetups that we did early on in the project. Useful then, but not any longer. It might have even predated Quick Dev. FYI - We have an opening for Metron Team Historian. Send a cover letter, CV and $150 application fee to me for consideration. :) On Fri, Oct 6, 2017 at 8:52 AM Justin Leet wrote: > What is the point of that anyway? It just looks like full dev with no > skipTags? That seems like it should just be documented that you can run > with Vagrant with '--ansible-skip-tags'? We probably should document any > tags you might want to skip anyway. > > I'm pretty in favor of killing that. > > On Fri, Oct 6, 2017 at 8:46 AM, Nick Allen wrote: > > > The same case might be made for the Code Lab Platform > > `metron-deployment/vagrant/codelab-platform`? > > > > On Fri, Oct 6, 2017 at 8:44 AM Justin Leet > wrote: > > > > > Wiki updated. It now points to full dev and the link just says "Dev > > > Platform" > > > > > > On Fri, Oct 6, 2017 at 8:39 AM, Nick Allen wrote: > > > > > > > +1 To killing Quick Dev and updating the Wiki. Quick Dev has been > > broken > > > > for eons. Simon's point about "profusion of installs" makes a lot of > > > sense > > > > too. > > > > > > > > > > > > > > > > On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < > > > > si...@simonellistonball.com> wrote: > > > > > > > > > +1 we see a lot of people struggling with the profusion of install > > and > > > > run > > > > > methods as it is, if we can reduce that surface area, life will be > a > > > lot > > > > > easier on the user list. > > > > > > > > > > > On 6 Oct 2017, at 13:28, zeo...@gmail.com > > wrote: > > > > > > > > > > > > I say we kill it and repoint the site. That will give us one > less > > > > thing > > > > > to > > > > > > upgrade to centos 7 as well. > > > > > > > > > > > > Jon > > > > > > > > > > > > On Fri, Oct 6, 2017, 08:27 Justin Leet > > > wrote: > > > > > > > > > > > >> So what are we going to do with Quick Dev? I'm pretty sure > > > > everybody's > > > > > >> been using full dev for awhile now (and quick dev is probably > > broken > > > > > since > > > > > >> I'm sure we haven't been regularly updating it). > > > > > >> > > > > > >> I just realized our website links to a wiki page that says to > use > > > > quick > > > > > >> dev. Given that quick dev is broken or behind or both, this is > > > going > > > > > to be > > > > > >> incredibly confusing and misleading to anyone wandering in. > > > > > >> > > > > > >> A short term fix is to just point that wiki page to full dev, so > > we > > > > > aren't > > > > > >> at least broken to anyone coming in. > > > > > >> > > > > > >> After that we should figure out what we're doing with quick and > > full > > > > dev > > > > > >> and take care of whatever needs to be done. > > > > > >> > > > > > >> Thoughts? > > > > > >> > > > > > >> Justin > > > > > >> > > > > > > -- > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > >
Re: Quick Dev
What is the point of that anyway? It just looks like full dev with no skipTags? That seems like it should just be documented that you can run with Vagrant with '--ansible-skip-tags'? We probably should document any tags you might want to skip anyway. I'm pretty in favor of killing that. On Fri, Oct 6, 2017 at 8:46 AM, Nick Allen wrote: > The same case might be made for the Code Lab Platform > `metron-deployment/vagrant/codelab-platform`? > > On Fri, Oct 6, 2017 at 8:44 AM Justin Leet wrote: > > > Wiki updated. It now points to full dev and the link just says "Dev > > Platform" > > > > On Fri, Oct 6, 2017 at 8:39 AM, Nick Allen wrote: > > > > > +1 To killing Quick Dev and updating the Wiki. Quick Dev has been > broken > > > for eons. Simon's point about "profusion of installs" makes a lot of > > sense > > > too. > > > > > > > > > > > > On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < > > > si...@simonellistonball.com> wrote: > > > > > > > +1 we see a lot of people struggling with the profusion of install > and > > > run > > > > methods as it is, if we can reduce that surface area, life will be a > > lot > > > > easier on the user list. > > > > > > > > > On 6 Oct 2017, at 13:28, zeo...@gmail.com > wrote: > > > > > > > > > > I say we kill it and repoint the site. That will give us one less > > > thing > > > > to > > > > > upgrade to centos 7 as well. > > > > > > > > > > Jon > > > > > > > > > > On Fri, Oct 6, 2017, 08:27 Justin Leet > > wrote: > > > > > > > > > >> So what are we going to do with Quick Dev? I'm pretty sure > > > everybody's > > > > >> been using full dev for awhile now (and quick dev is probably > broken > > > > since > > > > >> I'm sure we haven't been regularly updating it). > > > > >> > > > > >> I just realized our website links to a wiki page that says to use > > > quick > > > > >> dev. Given that quick dev is broken or behind or both, this is > > going > > > > to be > > > > >> incredibly confusing and misleading to anyone wandering in. > > > > >> > > > > >> A short term fix is to just point that wiki page to full dev, so > we > > > > aren't > > > > >> at least broken to anyone coming in. > > > > >> > > > > >> After that we should figure out what we're doing with quick and > full > > > dev > > > > >> and take care of whatever needs to be done. > > > > >> > > > > >> Thoughts? > > > > >> > > > > >> Justin > > > > >> > > > > > -- > > > > > > > > > > Jon > > > > > > > > > > > > > >
Re: Quick Dev
The same case might be made for the Code Lab Platform `metron-deployment/vagrant/codelab-platform`? On Fri, Oct 6, 2017 at 8:44 AM Justin Leet wrote: > Wiki updated. It now points to full dev and the link just says "Dev > Platform" > > On Fri, Oct 6, 2017 at 8:39 AM, Nick Allen wrote: > > > +1 To killing Quick Dev and updating the Wiki. Quick Dev has been broken > > for eons. Simon's point about "profusion of installs" makes a lot of > sense > > too. > > > > > > > > On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < > > si...@simonellistonball.com> wrote: > > > > > +1 we see a lot of people struggling with the profusion of install and > > run > > > methods as it is, if we can reduce that surface area, life will be a > lot > > > easier on the user list. > > > > > > > On 6 Oct 2017, at 13:28, zeo...@gmail.com wrote: > > > > > > > > I say we kill it and repoint the site. That will give us one less > > thing > > > to > > > > upgrade to centos 7 as well. > > > > > > > > Jon > > > > > > > > On Fri, Oct 6, 2017, 08:27 Justin Leet > wrote: > > > > > > > >> So what are we going to do with Quick Dev? I'm pretty sure > > everybody's > > > >> been using full dev for awhile now (and quick dev is probably broken > > > since > > > >> I'm sure we haven't been regularly updating it). > > > >> > > > >> I just realized our website links to a wiki page that says to use > > quick > > > >> dev. Given that quick dev is broken or behind or both, this is > going > > > to be > > > >> incredibly confusing and misleading to anyone wandering in. > > > >> > > > >> A short term fix is to just point that wiki page to full dev, so we > > > aren't > > > >> at least broken to anyone coming in. > > > >> > > > >> After that we should figure out what we're doing with quick and full > > dev > > > >> and take care of whatever needs to be done. > > > >> > > > >> Thoughts? > > > >> > > > >> Justin > > > >> > > > > -- > > > > > > > > Jon > > > > > > > > >
Re: Quick Dev
Wiki updated. It now points to full dev and the link just says "Dev Platform" On Fri, Oct 6, 2017 at 8:39 AM, Nick Allen wrote: > +1 To killing Quick Dev and updating the Wiki. Quick Dev has been broken > for eons. Simon's point about "profusion of installs" makes a lot of sense > too. > > > > On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < > si...@simonellistonball.com> wrote: > > > +1 we see a lot of people struggling with the profusion of install and > run > > methods as it is, if we can reduce that surface area, life will be a lot > > easier on the user list. > > > > > On 6 Oct 2017, at 13:28, zeo...@gmail.com wrote: > > > > > > I say we kill it and repoint the site. That will give us one less > thing > > to > > > upgrade to centos 7 as well. > > > > > > Jon > > > > > > On Fri, Oct 6, 2017, 08:27 Justin Leet wrote: > > > > > >> So what are we going to do with Quick Dev? I'm pretty sure > everybody's > > >> been using full dev for awhile now (and quick dev is probably broken > > since > > >> I'm sure we haven't been regularly updating it). > > >> > > >> I just realized our website links to a wiki page that says to use > quick > > >> dev. Given that quick dev is broken or behind or both, this is going > > to be > > >> incredibly confusing and misleading to anyone wandering in. > > >> > > >> A short term fix is to just point that wiki page to full dev, so we > > aren't > > >> at least broken to anyone coming in. > > >> > > >> After that we should figure out what we're doing with quick and full > dev > > >> and take care of whatever needs to be done. > > >> > > >> Thoughts? > > >> > > >> Justin > > >> > > > -- > > > > > > Jon > > > > >
Re: Quick Dev
+1 To killing Quick Dev and updating the Wiki. Quick Dev has been broken for eons. Simon's point about "profusion of installs" makes a lot of sense too. On Fri, Oct 6, 2017 at 8:33 AM Simon Elliston Ball < si...@simonellistonball.com> wrote: > +1 we see a lot of people struggling with the profusion of install and run > methods as it is, if we can reduce that surface area, life will be a lot > easier on the user list. > > > On 6 Oct 2017, at 13:28, zeo...@gmail.com wrote: > > > > I say we kill it and repoint the site. That will give us one less thing > to > > upgrade to centos 7 as well. > > > > Jon > > > > On Fri, Oct 6, 2017, 08:27 Justin Leet wrote: > > > >> So what are we going to do with Quick Dev? I'm pretty sure everybody's > >> been using full dev for awhile now (and quick dev is probably broken > since > >> I'm sure we haven't been regularly updating it). > >> > >> I just realized our website links to a wiki page that says to use quick > >> dev. Given that quick dev is broken or behind or both, this is going > to be > >> incredibly confusing and misleading to anyone wandering in. > >> > >> A short term fix is to just point that wiki page to full dev, so we > aren't > >> at least broken to anyone coming in. > >> > >> After that we should figure out what we're doing with quick and full dev > >> and take care of whatever needs to be done. > >> > >> Thoughts? > >> > >> Justin > >> > > -- > > > > Jon > >
Re: Quick Dev
+1 we see a lot of people struggling with the profusion of install and run methods as it is, if we can reduce that surface area, life will be a lot easier on the user list. > On 6 Oct 2017, at 13:28, zeo...@gmail.com wrote: > > I say we kill it and repoint the site. That will give us one less thing to > upgrade to centos 7 as well. > > Jon > > On Fri, Oct 6, 2017, 08:27 Justin Leet wrote: > >> So what are we going to do with Quick Dev? I'm pretty sure everybody's >> been using full dev for awhile now (and quick dev is probably broken since >> I'm sure we haven't been regularly updating it). >> >> I just realized our website links to a wiki page that says to use quick >> dev. Given that quick dev is broken or behind or both, this is going to be >> incredibly confusing and misleading to anyone wandering in. >> >> A short term fix is to just point that wiki page to full dev, so we aren't >> at least broken to anyone coming in. >> >> After that we should figure out what we're doing with quick and full dev >> and take care of whatever needs to be done. >> >> Thoughts? >> >> Justin >> > -- > > Jon
Re: Quick Dev
I say we kill it and repoint the site. That will give us one less thing to upgrade to centos 7 as well. Jon On Fri, Oct 6, 2017, 08:27 Justin Leet wrote: > So what are we going to do with Quick Dev? I'm pretty sure everybody's > been using full dev for awhile now (and quick dev is probably broken since > I'm sure we haven't been regularly updating it). > > I just realized our website links to a wiki page that says to use quick > dev. Given that quick dev is broken or behind or both, this is going to be > incredibly confusing and misleading to anyone wandering in. > > A short term fix is to just point that wiki page to full dev, so we aren't > at least broken to anyone coming in. > > After that we should figure out what we're doing with quick and full dev > and take care of whatever needs to be done. > > Thoughts? > > Justin > -- Jon
Quick Dev
So what are we going to do with Quick Dev? I'm pretty sure everybody's been using full dev for awhile now (and quick dev is probably broken since I'm sure we haven't been regularly updating it). I just realized our website links to a wiki page that says to use quick dev. Given that quick dev is broken or behind or both, this is going to be incredibly confusing and misleading to anyone wandering in. A short term fix is to just point that wiki page to full dev, so we aren't at least broken to anyone coming in. After that we should figure out what we're doing with quick and full dev and take care of whatever needs to be done. Thoughts? Justin
[GitHub] incubator-metron pull request #578: METRON-946 Full/Quick dev should default...
Github user asfgit closed the pull request at: https://github.com/apache/incubator-metron/pull/578 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #578: METRON-946 Full/Quick dev should default networ...
Github user mattf-horton commented on the issue: https://github.com/apache/incubator-metron/pull/578 and thanks for the quick check, @dlyle65535 . In process to commit... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #578: METRON-946 Full/Quick dev should default networ...
Github user dlyle65535 commented on the issue: https://github.com/apache/incubator-metron/pull/578 +1, ran it up in full dev. Everything worked as expected. Thanks for the quick turn, @mattf-horton. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron pull request #578: METRON-946 Full/Quick dev should default...
GitHub user mattf-horton opened a pull request: https://github.com/apache/incubator-metron/pull/578 METRON-946 Full/Quick dev should default network_host to [ _local_, _⦠## Contributor Comments @dlyle65535 observed that even single-node installs should have ES bind an external interface (as well as loopback) so that external clients can access ES reports. Based on that, FullDev assumes "node1" is bound to an external i/f, which didn't work with the latest. This patch will fix the problem. To test, install FullDev and see that the ES config is good. Also install single node manually and check ES config still good. There shouldn't be any other observable changes. ## Pull Request Checklist ### For all changes: - [x] Is there a JIRA ticket associated with this PR? If not one needs to be created at [Metron Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel). - [x] Does your PR title start with METRON- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? ### For code changes: - [x] Have you included steps to reproduce the behavior or problem that is being changed or addressed? - [x] Have you included steps or a guide to how the change may be verified and tested manually? - [NA] Have you ensured that the full suite of tests and checks have been executed in the root incubating-metron folder via: ``` mvn -q clean integration-test install && build_utils/verify_licenses.sh ``` - [NA] Have you written or updated unit tests and or integration tests to verify your changes? - [NA] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent? ### For documentation related changes: NA You can merge this pull request into a Git repository by running: $ git pull https://github.com/mattf-horton/incubator-metron METRON-946 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-metron/pull/578.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #578 commit 059cf98ce044c61935c8e8d82f46b57af42c8d50 Author: mattf-horton Date: 2017-05-10T02:45:44Z METRON-946 Full/Quick dev should default network_host to [ _local_, _site_ ] --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Failure to Deploy "Quick Dev"
nickwallen Thanks. On Wed, May 3, 2017 at 9:03 AM, David Lyle wrote: > Hi Nick, > > You do. just need to set up an Atlas account and shoot over the name. > > -D... > > > On Wed, May 3, 2017 at 8:44 AM, Nick Allen wrote: > > > Who has the credentials to be able to update the images on Atlas? > > > > On Fri, Apr 21, 2017 at 11:02 AM, Casey Stella > wrote: > > > > > I'm betting we need to regenerate the quickdev image after all the > mpack > > > changes. > > > > > > On Fri, Apr 21, 2017 at 10:45 AM, Otto Fowler > > > > wrote: > > > > > >> From lira: > > >> > > >> I 'think' that quickdev is actually build from full_dev, with metron > > >> installed already. So it may be that we need a new image built to make > > >> this > > >> not an upgrade situation? > > >> > > >> > > >> On April 21, 2017 at 10:37:39, Nick Allen (n...@nickallen.org) wrote: > > >> > > >> Not sure if I am doing something stupid, but I cannot deploy "Quick > Dev" > > >> from master currently. Full details in > > >> https://issues.apache.org/jira/browse/METRON-872. > > >> > > > > > > > > >
Re: Failure to Deploy "Quick Dev"
Achievement unlocked. On May 3, 2017 at 09:03:57, David Lyle (dlyle65...@gmail.com) wrote: Hi Nick, You do. just need to set up an Atlas account and shoot over the name. -D... On Wed, May 3, 2017 at 8:44 AM, Nick Allen wrote: > Who has the credentials to be able to update the images on Atlas? > > On Fri, Apr 21, 2017 at 11:02 AM, Casey Stella wrote: > > > I'm betting we need to regenerate the quickdev image after all the mpack > > changes. > > > > On Fri, Apr 21, 2017 at 10:45 AM, Otto Fowler > > wrote: > > > >> From lira: > >> > >> I 'think' that quickdev is actually build from full_dev, with metron > >> installed already. So it may be that we need a new image built to make > >> this > >> not an upgrade situation? > >> > >> > >> On April 21, 2017 at 10:37:39, Nick Allen (n...@nickallen.org) wrote: > >> > >> Not sure if I am doing something stupid, but I cannot deploy "Quick Dev" > >> from master currently. Full details in > >> https://issues.apache.org/jira/browse/METRON-872. > >> > > > > >
Re: Failure to Deploy "Quick Dev"
Hi Nick, You do. just need to set up an Atlas account and shoot over the name. -D... On Wed, May 3, 2017 at 8:44 AM, Nick Allen wrote: > Who has the credentials to be able to update the images on Atlas? > > On Fri, Apr 21, 2017 at 11:02 AM, Casey Stella wrote: > > > I'm betting we need to regenerate the quickdev image after all the mpack > > changes. > > > > On Fri, Apr 21, 2017 at 10:45 AM, Otto Fowler > > wrote: > > > >> From lira: > >> > >> I 'think' that quickdev is actually build from full_dev, with metron > >> installed already. So it may be that we need a new image built to make > >> this > >> not an upgrade situation? > >> > >> > >> On April 21, 2017 at 10:37:39, Nick Allen (n...@nickallen.org) wrote: > >> > >> Not sure if I am doing something stupid, but I cannot deploy "Quick Dev" > >> from master currently. Full details in > >> https://issues.apache.org/jira/browse/METRON-872. > >> > > > > >
Re: Failure to Deploy "Quick Dev"
Who has the credentials to be able to update the images on Atlas? On Fri, Apr 21, 2017 at 11:02 AM, Casey Stella wrote: > I'm betting we need to regenerate the quickdev image after all the mpack > changes. > > On Fri, Apr 21, 2017 at 10:45 AM, Otto Fowler > wrote: > >> From lira: >> >> I 'think' that quickdev is actually build from full_dev, with metron >> installed already. So it may be that we need a new image built to make >> this >> not an upgrade situation? >> >> >> On April 21, 2017 at 10:37:39, Nick Allen (n...@nickallen.org) wrote: >> >> Not sure if I am doing something stupid, but I cannot deploy "Quick Dev" >> from master currently. Full details in >> https://issues.apache.org/jira/browse/METRON-872. >> > >
Re: Quick Dev - Atlas Images
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 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 > 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 > 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 > > > ima
Re: Quick Dev - Atlas Images
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 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 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 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
> 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 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 > 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 > 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
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 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 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
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 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 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 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
>> 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 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 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
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 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 >
Quick Dev - Atlas Images
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: Failure to Deploy "Quick Dev"
I'm betting we need to regenerate the quickdev image after all the mpack changes. On Fri, Apr 21, 2017 at 10:45 AM, Otto Fowler wrote: > From lira: > > I 'think' that quickdev is actually build from full_dev, with metron > installed already. So it may be that we need a new image built to make this > not an upgrade situation? > > > On April 21, 2017 at 10:37:39, Nick Allen (n...@nickallen.org) wrote: > > Not sure if I am doing something stupid, but I cannot deploy "Quick Dev" > from master currently. Full details in > https://issues.apache.org/jira/browse/METRON-872. >
Re: Failure to Deploy "Quick Dev"
>From lira: I 'think' that quickdev is actually build from full_dev, with metron installed already. So it may be that we need a new image built to make this not an upgrade situation? On April 21, 2017 at 10:37:39, Nick Allen (n...@nickallen.org) wrote: Not sure if I am doing something stupid, but I cannot deploy "Quick Dev" from master currently. Full details in https://issues.apache.org/jira/browse/METRON-872.
Failure to Deploy "Quick Dev"
Not sure if I am doing something stupid, but I cannot deploy "Quick Dev" from master currently. Full details in https://issues.apache.org/jira/browse/METRON-872.
