metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <ceste...@gmail.com>
Subject Re: [VOTE] Release of Metron_0.1BETA_rc5
Date Wed, 30 Mar 2016 15:52:49 GMT
Taylor, I noticed that you have uploading to repository.apache.org in the
template for the release vote.  First, is that strictly required?  Second,
if so, are there instructions?  I'm having some problems uploading the
bundle created by the mvn repository plugin to a staging repo due to a
missing release profile (and I can't figure out where I might be able to
create such a thing..perhaps I need different or more karma for that sort
of thing?)

Casey

On Tue, Mar 29, 2016 at 10:03 PM, P. Taylor Goetz <ptgoetz@gmail.com> wrote:

> Okay, so you are using gitpubsub...
>
> To remove the website from the releas, the two easiest options I can think
> of are:
>
> 1. Just exclude the site directory from the source release.
> 2. Create a new, bare branch (e.g. "metron-site"), move the site content
> there, and ask infra to point to that branch for website publishing.
>
> -Taylor
>
> > On Mar 29, 2016, at 7:57 PM, Casey Stella <cestella@gmail.com> wrote:
> >
> > We are currently generating the site with jekyll and infra has something
> > setup that will pull the site from git.
> >
> > Casey
> >
> >> On Tue, Mar 29, 2016 at 7:55 PM, P. Taylor Goetz <ptgoetz@gmail.com>
> wrote:
> >>
> >> Yeah, I think that should cover it.
> >>
> >> In terms of licensing issues with the website code, I would recommend
> >> excluding it from the release. If it's not vital to building the metron
> >> runtime components, it doesn't need to be in a release.
> >>
> >> How are you currently generating and publishing the website? Svnpubsub?
> >>
> >> -Taylor
> >>
> >>>> On Mar 29, 2016, at 5:36 PM, Billie Rinaldi <billie@apache.org>
> wrote:
> >>>>
> >>>> On Tue, Mar 29, 2016 at 12:46 PM, Casey Stella <cestella@gmail.com>
> >> wrote:
> >>>>
> >>>> Regarding the use of effective_tld_names.dat, it is in use currently
> in
> >> the
> >>>> Whois enrichment adapter (for stripping top level domains from
> domains),
> >>>> but that adapter is not turned on in the tech preview.  That being
> said,
> >>>> it's likely we will want to use that file in the future.  Since this
> is
> >> a
> >>>> reference file and the reason for the binary-only exclusion is "By
> >>>> including only the object/binary form, there is less exposed surface
> >> area
> >>>> of the third-party work from which a work might be derived; this
> >> addresses
> >>>> the second guiding principle of this policy.", it would seem that its
> >>>> inclusion as a piece of reference data lessens the exposed surface
> area
> >>>> from which a work might be derived, no?
> >>>
> >>> I read that part as saying that it's only okay to include the binary
> >>> version; but since this is textual data there is no binary version of
> >> these
> >>> files that we could include.  However, I missed this part on my first
> >> read:
> >>> "For small amounts of source that is directly consumed by the ASF
> product
> >>> at runtime in source form, and for which that source is unmodified and
> >>> unlikely to be changed anyway (say, by virtue of being specified by a
> >>> standard), inclusion of appropriately labeled source is also permitted.
> >> An
> >>> example of this is the web-facesconfig_1_0.dtd, whose inclusion is
> >> mandated
> >>> by the JSR 127: JavaServer Faces specification."
> >>>
> >>> So it sounds like we could argue that these 3 files (which are all
> >>> identical) are a small amount of source, and we will be allowed to
> >> include
> >>> them with an appropriate reference in our LICENSE **as long as we never
> >>> modify the effective_tld_names.dat files**.
> >>>
> >>>
> >>>>
> >>>> Casey
> >>>>
> >>>>> On Tue, Mar 29, 2016 at 2:55 PM, Billie Rinaldi <billie@apache.org>
> >> wrote:
> >>>>>
> >>>>> These files have Mozilla Public License, which has an unusual policy
> >> that
> >>>>> says we should only include them in binary form (!) -- see
> >>>>> http://www.apache.org/legal/resolved.html#category-b.  Can we get
> rid
> >> of
> >>>>> them?
> >>
> metron-streaming/Metron-Common/src/test/resources/effective_tld_names.dat
> >>
> metron-streaming/Metron-MessageParsers/src/test/resources/effective_tld_names.dat
> >>
> metron-streaming/Metron-Topologies/src/main/resources/effective_tld_names.dat
> >>>>>
> >>>>> The files at metron-ui/lib/public/font/* seem to have SIL Open Font
> >>>> License
> >>>>> (https://github.com/FortAwesome/Font-Awesome#license), which has
the
> >>>> same
> >>>>> restriction, but they're okay since they're binary.  We need to
add
> >> their
> >>>>> info to our LICENSE.
> >>>>>
> >>>>> - checksums and signature are valid -- next time include a md5
> >> signature
> >>>>> - DISCLAIMER is correct -- file name should include "incubating"
but
> >>>>> "incubator" is close
> >>>>> - no binaries in source tarball
> >>>>> - build is successful
> >>>>>
> >>>>> Billie
> >>>>>
> >>>>> On Tue, Mar 22, 2016 at 3:56 PM, James Sirota <
> jsirota@hortonworks.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> A tag has been created for Metron_0.1BETA_RC5
> >>>>>>
> >>>>>> Github:
> >>
> https://github.com/apache/incubator-metron/releases/tag/Metron_0.1BETA_rc5
> >>>>>> Apache:
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=shortlog;h=refs/tags/Metron_0.1BETA_rc5
> >>>>>>
> >>>>>> With a Git hash:
> >>>>>> 443ad7baa2ce5c3127a9691c7d45b7a4a92e257b
> >>>>>>
> >>>>>> The code is staged at
> >>>>>> http://home.apache.org/~jsirota/metron/Metron_0.1BETA_RC/RC_5/
> >>>>>>
> >>>>>> The following are instructions for verifying the build.
> >>>>>>
> >>>>>> Step 1 – Build Metron
> >>>>>>
> >>>>>> cd incubator-metron/metron-streaming/
> >>>>>> mvn apache-rat:check && cd metron-streaming &&
mvn clean
> >>>> integration-test
> >>>>>> && cd ..
> >>>>>>
> >>>>>> Verify that all tests are passing
> >>>>>>
> >>>>>> Step 2 – Deploy metron as a single VM via vagrant and ansible
> >>>>>>
> >>>>>> cd deployment/vagrant/singlenode-vagrant
> >>>>>> vagrant plugin install vagrant-hostmanager
> >>>>>> vagrant up
> >>>>>>
> >>>>>> For a more complete set of instructions refer to:
> >>>>>> https://github.com/apache/incubator-metron/tree/master/deployment
> >>>>>>
> >>>>>> Verify metron is working:
> >>>>>> - Check Ambari to make sure all the services are up by going
to
> ambari
> >>>> in
> >>>>>> a browser at http://node1:8080
> >>>>>> - Check Storm to make sure all the topologies are up
> >>>>>>     From Ambari navigate to Storm -> Quick Links -> Storm
UI
> >>>>>> - Check that the enrichment topology has emitted some data (could
> take
> >>>> a
> >>>>>> few minutes to show up in the Storm UI)
> >>>>>> - Check indexes to make sure indexing is done correctly and
data is
> >>>>>> visualized in Kibana in a browser at http://node1:5000
> >>>>>> - Check that some data is written into HDFS for at least one
of the
> >>>> data
> >>>>>> sources
> >>>>>>     Look in HDFS under
> >>>>>> /apps/metron/enrichment/indexed/yaf_doc|bro_doc|snort_doc
> >>>>>>     This can be done from the browser by going to
> >>>>>> http://node:50070/explorer.html#/apps/metron/enrichment/indexed
> >>>>>>
> >>>>>> Step 3 (optional) – Verify AWS Multi-Node Deploy with Ansible
> >>>>>> cd deployment/amazon-ec2
> >>>>>> ansible-playbook -i ec2.py playbook.yml
> >>>>>>
> >>>>>> For a more complete set of instructions refer to:
> >>>>>> https://github.com/apache/incubator-metron/tree/master/deployment
> >>>>>>
> >>>>>> To verify the working build go through the same verifications
as in
> >>>>> Step2,
> >>>>>> but on AWS.  Reference playbook.yml for location of the services.
> >>>>>> Ambari-master contains Ambari, web contains Kibana and sensors.
> >>>>>>
> >>>>>> Please vote +1 if you approve and –1 if you do not approve.
 Also,
> >>>> please
> >>>>>> indicate if your
> >>>>>> vote is binding
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message