metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Bittmann <m...@b23.io>
Subject Re: [VOTE] Release of Metron_0.1BETA_rc3
Date Fri, 19 Feb 2016 15:27:39 GMT
Thanks Larry for catching the header on the ansible module. That's my fault for not being more
careful. It is not currently part of the Ansible distribution. As Casey pointed out, it is
in a PR under review. If it ever made its way into the Ansible product as GPL, then we would
remove the file entirely from the Metron codebase since it would be maintained and shipped
with Ansible. 

As the original author, I'm not sure whether I can simply change version in Metron and remove
it if/when adopted. If so, the file would then exist in two places at once, as a pending PR
to an external project with GPL header and in ASF codebase with ASF license. I'm no lawyer,
so I would welcome any feedback as to whether that strategy violates two licenses at once.
Another option would be to abandon the module and take this approach for setting up the Ambari
cluster: https://github.com/seanorama/ansible-ambari/tree/master/roles/blueprint. You lose
some convenience and nicer error reporting. I suppose I could cancel the existing PR, but
I do believe there is community value to the module. Whatever we decide, I'll make sure to
clean it up this weekend. Thanks again Larry for your oversight and helping us on this process.




On 2/19/16, 9:58 AM, "Casey Stella" <cestella@gmail.com> wrote:

>No problem!  We're on our way to the next RC now with the other issues.
>But, before that can happen, I wanted to give a bit more context to the GPL
>issue.
>
>It appears that the file in question was submitted to ansible and is in the
>"community review" stage, so it has not been merged with ansible.  Relevant
>PR: https://github.com/ansible/ansible-modules-extras/pull/1226
>It was subsequently contributed here.
>
>I expect this means that it's not as simple as just asking Mark to change
>the license, but I don't know.  Any guidance would be greatly appreciated.
>
>Casey
>
>
>On Fri, Feb 19, 2016 at 9:39 AM, larry mccay <lmccay@apache.org> wrote:
>
>> Thanks for the verification instructions, Casey!
>> I strongly encourage folks to manually test in this way as well.
>> Then indicate along with your vote exactly what was tested.
>> This allows for ensuring that the integration test is actually working
>> properly and exactly what sort of functional testing coverage there was for
>> the vote.
>>
>> The KEYS file within the source tree...
>> I'm not sure whether it will create any actual problem but it certainly
>> becomes something that could get out of sync with what is used to verify
>> the signatures. Keep in mind that this is used to ensure that the release
>> archive hasn't been tampered with. If for whatever reason someone uses the
>> KEYS file within the source archive to verify the signature it would
>> invalidate the test. Tampering with the archive and replacing the KEYS file
>> with one that will verify would not be detectable.
>>
>> I don't have enough context regarding the GPL header. It claims that the
>> file is part of ansible with which is apparently GPL'd technology and
>> cannot be redistributed in an ASL release. Including such a file requires
>> the entire project to be GPL. If this file and any others truly are from
>> ansible then they need to be removed.
>>
>> You are making good progress toward getting this release out!
>> The first one is always the toughest.
>> Once we get all these painful nuances taken care of subsequent releases
>> will be much easier.
>> It is important to get it as right as possible the first release - so that
>> it is easier going forward.
>>
>>
>> On Fri, Feb 19, 2016 at 9:13 AM, Casey Stella <cestella@gmail.com> wrote:
>>
>> > At least regarding the Keys, we were following Apache Wave's (
>> > https://github.com/apache/incubator-wave)  model who kept their keys in
>> > the
>> > source repo.  I figured it would be a good idea so it was a known place.
>> > Is there harm in keeping it there?  Certainly, we'll want to merge the
>> > existing keys file with Owen and Billie's keys in.
>> >
>> > Regarding verification, we have taken some pains to have an end-to-end
>> > integration tests as a junit test available this release, so at the very
>> > least ensure that mvn integration-test runs (though this is prerequisite
>> > for any commit).
>> > That being said, running vagrant up from
>> > the deployment/vagrant/singlenode-vagrant/ directory will spin up a
>> single
>> > node VM with the software installed and running so you can play with it
>> > further.  I would warn you that it's a bit overcommitted resource-wise at
>> > the moment and components are prone to crash due to lack of memory, so be
>> > aware of that.
>> >
>> > What I normally do is:
>> >
>> >    - stop all of the storm topologies other than pcap
>> >    - run some traffic through there by pinging or wget'ing
>> >    - Check that I'm seeing values in the elastic search index
>> >       - Check to see that an index was created: curl
>> >       http://node1:9200/_cat/indices?v
>> >       - Check indexed values (assuming index name is
>> >       pcap_index_2016.02.13.06 is the index): curl "
>> >
>> >
>> http://node1:9200/pcap_index_2016.02.13.06/_search?pretty=true&q=*:*&size=28000
>> > "
>> >       | python -m json.tool | vi -
>> >       - Check that pcap raw data is making it to hbase via the hbase
>> shell
>> >    in the pcap_test table
>> >
>> > Generally this is what's being done in the integration test called
>> > PCapIntegrationTest.
>> >
>> > The missing headers should be corrected, obviously, before the next RC.
>> >
>> > I am not sure what to go through to about the GPL license on the
>> > ambari_cluster_state.py.  Mark committed it, is there more to be done
>> than
>> > have Mark agree to re-license with Apache or is there some other more
>> > official legal process that we have to go through?
>> >
>> > Casey
>> >
>> >
>> >
>> > On Thu, Feb 18, 2016 at 8:38 PM, larry mccay <lmccay@apache.org> wrote:
>> >
>> > > Is there any Metron specific functional testing that can be performed
>> as
>> > > criteria for giving a +1?
>> > > Can we use the ansible scripts to fire up a deployment and manually
>> check
>> > > anything?
>> > >
>> > > It's usually good to be able to specific a +1 and the list of things
>> that
>> > > you tested.
>> > >
>> > > Metro should have a staging directory inside of:
>> > > https://dist.apache.org/repos/dist/dev/incubator/.
>> > >
>> > > I notice that there is already a release dir:
>> > > https://dist.apache.org/repos/dist/release/incubator/metron/ and that
>> > > within this there is a KEYS file with Billie's and Owen's keys included
>> > > this is not the KEYS file used for this release candidate which may be
>> > okay
>> > > but having Billie's and Owen's in there help it be trusted by more
>> folks
>> > > when verifying the signatures.
>> > >
>> > > I am not sure that you want the KEYS file inside the source tree.
>> > >
>> > > There are missing Apache headers in a many files.
>> > > All scripts, config files, descriptors must have Apache headers.
>> > >
>> > > ambari_cluster_state.py has the following GNU license header which I do
>> > not
>> > > believe ASL friendly:
>> > >
>> > > # Author: Mark Bittmann (https://github.com/mbittmann)
>> > > # This file is part of Ansible
>> > > #
>> > > # Ansible is free software: you can redistribute it and/or modify
>> > > # it under the terms of the GNU General Public License as published by
>> > > # the Free Software Foundation, either version 3 of the License, or
>> > > # (at your option) any later version.
>> > > #
>> > > # Ansible is distributed in the hope that it will be useful,
>> > > # but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > > # GNU General Public License for more details.
>> > > #
>> > > # You should have received a copy of the GNU General Public License
>> > > # along with Ansible.  If not, see <http://www.gnu.org/licenses/>.
>> > >
>> > > Unfortunately, I have to give a -1 until these issues are corrected -
>> or
>> > > someone corrects my understanding.
>> > >
>> > >
>> > >
>> > > On Thu, Feb 18, 2016 at 6:05 PM, Charles Porter <
>> > > opensource.charles@gmail.com> wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On Thu, Feb 18, 2016 at 2:39 PM, James Sirota <
>> jsirota@hortonworks.com
>> > >
>> > > > wrote:
>> > > >
>> > > > > A tag has been created for Metron_0.1BETA_rc3:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=shortlog;h=refs/tags/Metron_0.1BETA_rc3
>> > > > >
>> > > > > With a Git hash:
>> > > > > 5ceee2a44ff777d3e980406c4a70efc9297e5350
>> > > > >
>> > > > > And a KEYS file:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=blob_plain;f=KEYS;hb=refs/heads/Metron_0.1BETA
>> > > > >
>> > > > > And a staging directory:
>> > > > > http://people.apache.org/~jsirota/metron/
>> > > > >
>> > > > > Please verify the release and vote.  The vote will close on Monday,
>> > > Feb.
>> > > > > 22nd.
>> > > > >
>> > > > > Instructions for evaluating the build are posted here under
>> “Release
>> > > > > Checklist":
>> > > > > http://incubator.apache.org/guides/releasemanagement.html
>> > > > >
>> > > > > Please vote +1 if you approve and –1 if you do not approve.
 Also,
>> > > please
>> > > > > indicate if your vote is binding
>> > > > >
>> > > >
>> > >
>> >
>>
Mime
View raw message