metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Otto Fowler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (METRON-761) STELLAR should know it's execution context and functions should have an annotation that denotes if they are restricted to an execution environment
Date Fri, 10 Mar 2017 04:06:37 GMT

     [ https://issues.apache.org/jira/browse/METRON-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Otto Fowler updated METRON-761:
-------------------------------
    Description: 
We are adding new Stellar functionality, and have 2 environments
where that functionality can be executed.

Some functions however, will not make sense in all environments.  Between the SHELL and STORM,
some things just are not going to work.

For example, executing a script, assumes the script is available on all the storm nodes, requires
a user and possibly sudo access.  This may not make sense from storm, but may make sense from
the SHELL.

Stellar should 'know' it's context, and only load functions that fit into that context.

Currently we use "capability" checks to required things, and that includes:
Optional<Object> console =  context.getCapability(CONSOLE, false);
see: ShellFunctions.java

But this requires the author to do it correctly in the code.  If we make it attributed then
we can prevent loading and filter out.   In other words there may be a difference between
required capability and applicability

This would also allow for non-runtime verification

  was:
We are adding new Stellar functionality, and have 2 environments
where that functionality can be executed.

Some functions however, will not make sense in all environments.  Between the SHELL and STORM,
some things just are not going to work.

For example, executing a script, assumes the script is available on all the storm nodes, requires
a user and possibly sudo access.  This may not make sense from storm, but may make sense from
the SHELL.

Stellar should 'know' it's context, and only load functions that fit into that context.

Currently we use "capability" checks to required things, and that includes:
Optional<Object> console =  context.getCapability(CONSOLE, false);
see: ShellFunctions.java

But this requires the author to do it correctly in the code.  If we make it attributed then
we can prevent loading and filter out.   In other words there may be a difference between
required capability and applicability


> STELLAR should know it's execution context and functions should have an annotation that
denotes if they are restricted to an execution environment
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: METRON-761
>                 URL: https://issues.apache.org/jira/browse/METRON-761
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Otto Fowler
>            Assignee: Otto Fowler
>              Labels: shell, stellar
>
> We are adding new Stellar functionality, and have 2 environments
> where that functionality can be executed.
> Some functions however, will not make sense in all environments.  Between the SHELL and
STORM, some things just are not going to work.
> For example, executing a script, assumes the script is available on all the storm nodes,
requires a user and possibly sudo access.  This may not make sense from storm, but may make
sense from the SHELL.
> Stellar should 'know' it's context, and only load functions that fit into that context.
> Currently we use "capability" checks to required things, and that includes:
> Optional<Object> console =  context.getCapability(CONSOLE, false);
> see: ShellFunctions.java
> But this requires the author to do it correctly in the code.  If we make it attributed
then we can prevent loading and filter out.   In other words there may be a difference between
required capability and applicability
> This would also allow for non-runtime verification



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message