Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

METRON-1091 Package STELLAR shell as stand alone #690

Closed
wants to merge 15 commits into from

Conversation

ottobackwards
Copy link
Contributor

@ottobackwards ottobackwards commented Aug 11, 2017

This PR adds metron-deployment/packaging/archive, and the metron-stellar-shell module.
This PR adds a second archive product ( ${}-stand-alone.tar.gz ) to stellar-common.

This module packages a stellar shell environment that allows running stellar on a workstation that is not a dev/build machine, nor is a cluster node.

The idea is that a metron 'admin' may want to run stellar commands on his local machine.

Remote management ( config_get etc ) and profile would be useful, but have not been included. I do not believe it is realistic for the expected user to open firewall ports or have the 'confs' setup to have these functions work as they would on a metron cluster node.

This use case would seem to require REST support of some kind. Maybe a /metron-interface/metron-rest-stellar module. Or maybe when extensions come to stellar we can just do it as an extension.

Also a problem, is that there are management functions that bring in hadoop dependencies mixed in with other functions like SHELL_EDIT() that may be useful on their own.

Testing

  • package
    - take /metron-deployment/packaging/archive/metron-stellar-shell/target/metron-stellar-shell-0.4.1-archive.tar.gz and unpack it in some directory
    take metron-stellar/stellar-common/target/stellar-common-0.4.1-stand-alone.tar.gz and unpack it in some directory
  • run it
  • `stellar it up

Questions for reviewers

  • Where should the doc for this go?
  • What NOTICE or other Files should be in the deployed env?
  • Do we want to post this as a separate download?
  • Above questions wrt port opening and configuration

Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.

In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:

For all changes:

  • Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
  • Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
  • Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

  • Have you included steps to reproduce the behavior or problem that is being changed or addressed?

  • Have you included steps or a guide to how the change may be verified and tested manually?

  • Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:

    mvn -q clean integration-test install && build_utils/verify_licenses.sh 
    
  • Have you written or updated unit tests and or integration tests to verify your changes?

  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

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

  • Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html:

    cd site-book
    mvn site
    

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

New archive area under packaging for things packaged as archives
New stellar script that doesn't rely on having bigtop installed
@JonZeolla
Copy link
Member

JonZeolla commented Aug 13, 2017

+1, visual inspection + a bit of playing around (see below). Probably worth a README update to mention this exists?

~/bin$ ./stellar
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
log4j:WARN No appenders could be found for logger (org.apache.metron.stellar.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Stellar, Go!
Please note that functions are loading lazily in the background and will be unavailable until loaded fully.
[Stellar]>>> Functions loaded, you may refer to functions now...

[Stellar]>>> TO_DOUBLE(2)
2.0
[Stellar]>>> TO_INTEGER(SQRT(64))
8
[Stellar]>>> TO_UPPER('ThIS is A TEsT of MetRoN-1091')
THIS IS A TEST OF METRON-1091
[Stellar]>>> CHOP('2093j0f29k30fk230f2j309jf')
2093j0f29k30fk230f2j309j
[Stellar]>>> COUNT_MATCHES('the quick brown fox jumped over the lazy dog', 'o')
4
[Stellar]>>> DAY_OF_YEAR(1502592512)
18
[Stellar]>>> DAY_OF_MONTH(1502592512)
18
~$ bin/stellar
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
log4j:WARN No appenders could be found for logger (org.apache.metron.stellar.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Stellar, Go!
Please note that functions are loading lazily in the background and will be unavailable until loaded fully.
[Stellar]>>> Functions loaded, you may refer to functions now...

[Stellar]>>> DAY_OF_YEAR(1502592893)
18
[Stellar]>>> DAY_OF_MONTH(1502592893)
18
[Stellar]>>> COUNT_MATCHES('the quick brown fox jumped over the lazy dog', 'o')
4

Opened METRON-1107 for the DAY_OF_{YEAR,MONTH} issue, otherwise looks good to me.

@ottobackwards
Copy link
Contributor Author

@JonZeolla Thanks for the review!
There are several questions in the description that I think need to fall out of the review, one of them is where or how to document this.

Any ideas?

@JonZeolla
Copy link
Member

Some ideas:

  • Where should the doc for this go?
    • I would suggest under here.
  • Do we want to post this as a separate download?
    • Probably not IMO, this is a bit more of a niche tool.
  • Above questions wrt port opening and configuration
    • Probably handle as a follow-on, if at all.

@cestella
Copy link
Member

Are we packaging up the RPMs correctly to ship the stellar shell after this work has been done? Have we tried this in full-dev?

@ottobackwards
Copy link
Contributor Author

Casey, this adds a new packaging subfolder -> archive, and generates a new artifact ( the tar.gz ).
It does not effect the current deployment of the stellar shell as a part of metron.

I put it in deployment / packaging as default for 2 reasons:

  1. If we do include profiler/management etc that makes this a metron thing and not a stellar thing
  2. We don't have any packaging outside of deployment

Both of those things are up for discussion.

an RPM of the shell for RPM deployment to NON metron nodes could be a follow on.


Comments from Reviewable

@cestella
Copy link
Member

I just want to make sure that we didn't break backwards compatibility and have the shell not deployed as part of the mpack, I guess ;)

<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<commons.config.version>1.10</commons.config.version>
<metron_dir>${project.parent.relativePath}/..</metron_dir>
</properties>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm not a build-and-deployment expert, but shouldn't this pom have a dependency on stellar-common? Perhaps, with or without the exclusions:

        <dependency>
            <groupId>org.apache.metron</groupId>
            <artifactId>stellar-common</artifactId>
            <classifier>uber</classifier>
            <version>${project.parent.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>log4j</groupId>
                    <artifactId>log4j</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

The copy-resources could, if desired, then be replaced by usage in the assembly.xml of a dependencySet reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not an expert either. I copied what that docker-rpm pom does, because it does similar resource things.

@ottobackwards
Copy link
Contributor Author

bump - any comments on this? Any ideas for deployment? can we leave for later?

@ottobackwards
Copy link
Contributor Author

@JonZeolla I don't want to document it in the stellar-common module.
Stellar is being broken out of metron. The packaging of stellar as a shell, with the likely inclusion of metron-* stellar functions is a 'metron' thing. not a stellar thing.

At least that is what I'm thinking. So this is a metron custom deployment of the shell. I could change it to the default stand alone deployment of the shell for stellar, but I didn't think that was the right way to start out, at the time at least.

We could do it as the default archive of stellar common, and then do another archive of metron stellar jars.

So the usage would be:

unpack shell package
unpack metron-stellar-package into lib

@ottobackwards
Copy link
Contributor Author

I'm going to close this and refactor

@JonZeolla
Copy link
Member

Right, I think the disconnect is that I would envision a stellar shell with metron stellar functions added as libs, as you suggested. That's why I was thinking we would doc in stellar-common, I missed that this includes management/profiler functions.

@ottobackwards ottobackwards reopened this Aug 31, 2017
@ottobackwards
Copy link
Contributor Author

I have refactored this to be stellar centric.
We will create a second archive for the stand alone shell from stellar-common.
I also documented it in the stellar README.md.

The questions about NOTICE, LIC, README for deployment still apply.

@JonZeolla
Copy link
Member

Can you deconflict? I'd like to retest and review your questions again, but at a quick glance I think my prior suggestions stand, and for your NOTICE question, I'm not sure.

@ottobackwards
Copy link
Contributor Author

Sorry , it has been a while, I'll try to get it set

@ottobackwards
Copy link
Contributor Author

Hopefully it is all set @JonZeolla

Copy link
Member

@JonZeolla JonZeolla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 pending a sufficient response to the NOTICE/LICENSE question and my comments

operating system.

```bash
metron-stellar/stellar-common/target/stellar-common-0.4.1-stand-alone.tar.gz
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/0\.4\.1/0.4.2/

├── bin
│   └── stellar
└── lib
└── stellar-common-0.4.1-uber.jar
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/0\.4\.1/0.4.2/


By default the shell will have the base Stellar Language commands available. Any jars in the lib directory
that contain Stellar functions will also be loaded, and their commands will be available to shell, as long
as their dependencies are satisfied.
Copy link
Member

@JonZeolla JonZeolla Nov 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can be a little bit more explicit that, by default, not all stellar functions will work in the standalone shell. For instance, clarifying that only functions available listed in response to %functions will be included may be enough? I quickly noted that BIN, HLLP_*, STATS_*, OUTLIER_MAD_*, etc. weren't in there as profiler/management commands aren't included. Maybe we say that as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this could be more clear, but I don't think this is the PR for it. I think in general we need to either document or provide some more information through the functions on what should be included.

IE: Move the documentation so that the stellar/README only has things in stellar-common -or-
decorate which lib needs to be included with each function in the doc etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about if you just change it from:
have the base Stellar Language commands
to
have only the base Stellar Language commands
?

I'm not looking to explicitly mention what functions would not exist here, and why, but simply make it more obvious that things will be missing here by default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think moving the functions OUT of stellar common, now that it is broken out is the right thing™ to do

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that it should be a little bit more explicit that some Stellar functions won't be available by default (without needing to explicitly outline which). Something like:
By default the shell is limited to only the base Stellar common language commands.

@mmiklavc
Copy link
Contributor

mmiklavc commented Jan 8, 2018

This looks reasonable to me @ottobackwards. I'm +1 pending any further work per @JonZeolla's comments. Thanks for the contribution!

@ottobackwards
Copy link
Contributor Author

@JonZeolla this should be set

Copy link
Member

@JonZeolla JonZeolla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 as-is, but I made some optional documentation suggestions.


By default the shell will have the base Stellar Language commands available. Any jars in the lib directory
that contain Stellar functions will also be loaded, and their commands will be available to shell, as long
as their dependencies are satisfied.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that it should be a little bit more explicit that some Stellar functions won't be available by default (without needing to explicitly outline which). Something like:
By default the shell is limited to only the base Stellar common language commands.

├── bin
│   └── stellar
└── lib
└── stellar-common-0.4.2-uber.jar
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional: Update to 0.4.3. Only mentioning because I saw you updated this in the past from 0.4.1 to 0.4.2.

operating system.

```bash
metron-stellar/stellar-common/target/stellar-common-0.4.2-stand-alone.tar.gz
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional: Update to 0.4.3. Only mentioning because I saw you updated this in the past from 0.4.1 to 0.4.2.

@ottobackwards
Copy link
Contributor Author

Done, let me know if the changes are sufficient @JonZeolla

@asfgit asfgit closed this in 124becd Jan 30, 2018
@JonZeolla
Copy link
Member

Perfect, ty.

iraghumitra pushed a commit to iraghumitra/incubator-metron that referenced this pull request Feb 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
5 participants