[jira] [Closed] (APEXCORE-801) Committer guidelines for dependency CVE failures

[Thomas Weise (JIRA)]

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

Thomas Weise closed APEXCORE-801.
-

> Committer guidelines for dependency CVE failures
> 
>
> Key: APEXCORE-801
> URL: https://issues.apache.org/jira/browse/APEXCORE-801
> Project: Apache Apex Core
>  Issue Type: Documentation
>  Components: Website
>Reporter: Pramod Immaneni
>Assignee: Pramod Immaneni
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (APEXCORE-801) Committer guidelines for dependency CVE failures

[Thomas Weise (JIRA)]

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

Thomas Weise updated APEXCORE-801:
--
Fix Version/s: (was: 3.7.0)

> Committer guidelines for dependency CVE failures
> 
>
> Key: APEXCORE-801
> URL: https://issues.apache.org/jira/browse/APEXCORE-801
> Project: Apache Apex Core
>  Issue Type: Documentation
>  Components: Website
>Reporter: Pramod Immaneni
>Assignee: Pramod Immaneni
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (APEXCORE-801) Committer guidelines for dependency CVE failures

[Pramod Immaneni (JIRA)]

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

Pramod Immaneni resolved APEXCORE-801.
--
   Resolution: Fixed
Fix Version/s: 3.7.0

> Committer guidelines for dependency CVE failures
> 
>
> Key: APEXCORE-801
> URL: https://issues.apache.org/jira/browse/APEXCORE-801
> Project: Apache Apex Core
>  Issue Type: Documentation
>  Components: Website
>Reporter: Pramod Immaneni
>Assignee: Pramod Immaneni
> Fix For: 3.7.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [Proposal] Simulate setting for application launch

[Pramod Immaneni]

Asking users to create plugins for something they want to do in their
application logic is to do things in an indirect and cumbersome way with an
added level of complexity. I don't think users will elect to do that. There
is a reason populateDAG and the operators give users the flexibility they
do today to have any custom logic they want. populateDAG isn't only for
returning a constant DAG for an application, the configuration that is
passed today to populateDAG, apart from hadoop environmental properties
that could be considered constant also includes a variable component, which
is the user customizable configuration properties. There are already
examples of applications that have used these properties to do something
different. Apart from the properties, some attributes are also injected
into the DAG in a deliberate fashion by the platform to provide user with
these so they can create the dag accordingly. One example is a websocket
gateway address. If this is present applications create a websocket output
operator else they end up create a console or some other output operator.

On Thu, Dec 21, 2017 at 8:27 AM, Vlad Rozov  wrote:

> "Sometimes" is not a use case. Config is not a context.
>
> Without concrete use cases the proposed change is not well justified.
> populateDAG() is supposed to populate DAG, not to record anything in an
> external system. It was a design goal for plugins.
>
> Thank you,
>
> Vlad
>
>
> On 12/20/17 02:23, Priyanka Gugale wrote:
>
>> +1
>> Sometimes this context is required. We shouldn't change any default
>> behaviour other than making this config available.
>>
>> -Priyanka
>>
>>
>>
>> On Wed, Dec 20, 2017 at 5:32 AM, Pramod Immaneni 
>> wrote:
>>
>> The external system recording was just an example, not a specific use
>>> case.
>>> The idea is to provide comprehensive information to populateDAG as to the
>>> context it is being called under. It is akin to the test mode or simulate
>>> flag that you see with various utilities. The platform cannot control
>>> what
>>> populateDAG does, even without this information, in multiple calls that
>>> you
>>> mention the application can return different DAGs by depending on
>>> any external factor such as time of day or some external variable. This
>>> is
>>> to merely provide more context information in the config. It is upto the
>>> application to do what it wishes with it.
>>>
>>> On Tue, Dec 19, 2017 at 2:28 PM, Vlad Rozov  wrote:
>>>
>>> -0.5: populateDAG() may be called by the platform as many times as it
 needs (even in case it calls it only once now to launch an application).
 Passing different parameters to populateDAG() in simulate launch mode
 and
 actual launch may lead to different DAG being constructed for those two
 modes. Can't the use case you described be handled by a plugin?

 Thank you,

 Vlad


 On 12/19/17 10:06, Sanjay Pujare wrote:

 +1 although I prefer something that is more enforceable. So I like the
> idea
> of another method but that introduces incompatibility so may be in 4.0?
>
> On Tue, Dec 19, 2017 at 9:40 AM, Munagala Ramanath <
> amberar...@yahoo.com.invalid> wrote:
>
>+1
>
>> Ram
>>   On Tuesday, December 19, 2017, 8:33:21 AM PST, Pramod Immaneni <
>> pra...@datatorrent.com> wrote:
>>
>>I have a mini proposal. The command get-app-package-info runs the
>> populateDAG method of an application to construct the DAG but does not
>> actually launch the DAG. An application developer does not know in
>>
> which
>>>
 context the populateDAG is being called. For example, if they are
>> recording
>> application starts in an external system from populateDAG, they will
>>
> have
>>>
 false entries there. This can be solved in different ways such as
>> introducing another method in StreamingApplication or more parameters
>> to populateDAG but a non disruptive option would be to add a property
>>
> in
>>>
 the configuration object that is passed to populateDAG to indicate if
>>
> it
>>>
 is
>> simulate/test mode or real launch. An application developer can use
>>
> this
>>>
 property to take the appropriate actions.
>>
>> Thanks
>>
>>
>>
>>
>

Re: [Proposal] Simulate setting for application launch

[Sanjay Pujare]

It is relatively easy to describe the justification for this change without
getting into the weeds and hairsplitting words.

A DAG is built not only to launch an application but also to let a user
visualize and configure it. Currently "populateDAG" is the only method we
require application writers to implement and they implement it with the
goal of running the application. So it can use properties, configuration
and code that is really only needed if you want to "run" the DAG.

As mentioned above a perfectly valid use case is that a platform allows a
user to construct a DAG, visualize it and then attach configuration values
to various components in the DAG, save these values as some kind of a
"configuration package" and then at a future date run the DAG with this
setup. This is consistent with the view that construction of a pipeline and
execution of the pipeline are 2 separate phases and should be delineated as
such.

If you understand and agree with the justification we can work on improving
the original proposal.

Sanjay


On Thu, Dec 21, 2017 at 8:27 AM, Vlad Rozov  wrote:

> "Sometimes" is not a use case. Config is not a context.
>
> Without concrete use cases the proposed change is not well justified.
> populateDAG() is supposed to populate DAG, not to record anything in an
> external system. It was a design goal for plugins.
>
> Thank you,
>
> Vlad
>
>
> On 12/20/17 02:23, Priyanka Gugale wrote:
>
>> +1
>> Sometimes this context is required. We shouldn't change any default
>> behaviour other than making this config available.
>>
>> -Priyanka
>>
>>
>>
>> On Wed, Dec 20, 2017 at 5:32 AM, Pramod Immaneni 
>> wrote:
>>
>> The external system recording was just an example, not a specific use
>>> case.
>>> The idea is to provide comprehensive information to populateDAG as to the
>>> context it is being called under. It is akin to the test mode or simulate
>>> flag that you see with various utilities. The platform cannot control
>>> what
>>> populateDAG does, even without this information, in multiple calls that
>>> you
>>> mention the application can return different DAGs by depending on
>>> any external factor such as time of day or some external variable. This
>>> is
>>> to merely provide more context information in the config. It is upto the
>>> application to do what it wishes with it.
>>>
>>> On Tue, Dec 19, 2017 at 2:28 PM, Vlad Rozov  wrote:
>>>
>>> -0.5: populateDAG() may be called by the platform as many times as it
 needs (even in case it calls it only once now to launch an application).
 Passing different parameters to populateDAG() in simulate launch mode
 and
 actual launch may lead to different DAG being constructed for those two
 modes. Can't the use case you described be handled by a plugin?

 Thank you,

 Vlad


 On 12/19/17 10:06, Sanjay Pujare wrote:

 +1 although I prefer something that is more enforceable. So I like the
> idea
> of another method but that introduces incompatibility so may be in 4.0?
>
> On Tue, Dec 19, 2017 at 9:40 AM, Munagala Ramanath <
> amberar...@yahoo.com.invalid> wrote:
>
>+1
>
>> Ram
>>   On Tuesday, December 19, 2017, 8:33:21 AM PST, Pramod Immaneni <
>> pra...@datatorrent.com> wrote:
>>
>>I have a mini proposal. The command get-app-package-info runs the
>> populateDAG method of an application to construct the DAG but does not
>> actually launch the DAG. An application developer does not know in
>>
> which
>>>
 context the populateDAG is being called. For example, if they are
>> recording
>> application starts in an external system from populateDAG, they will
>>
> have
>>>
 false entries there. This can be solved in different ways such as
>> introducing another method in StreamingApplication or more parameters
>> to populateDAG but a non disruptive option would be to add a property
>>
> in
>>>
 the configuration object that is passed to populateDAG to indicate if
>>
> it
>>>
 is
>> simulate/test mode or real launch. An application developer can use
>>
> this
>>>
 property to take the appropriate actions.
>>
>> Thanks
>>
>>
>>
>>
>

Re: [Proposal] Simulate setting for application launch

[Vlad Rozov]

"Sometimes" is not a use case. Config is not a context.

Without concrete use cases the proposed change is not well justified. 
populateDAG() is supposed to populate DAG, not to record anything in an 
external system. It was a design goal for plugins.


Thank you,

Vlad

On 12/20/17 02:23, Priyanka Gugale wrote:

+1
Sometimes this context is required. We shouldn't change any default
behaviour other than making this config available.

-Priyanka



On Wed, Dec 20, 2017 at 5:32 AM, Pramod Immaneni 
wrote:


The external system recording was just an example, not a specific use case.
The idea is to provide comprehensive information to populateDAG as to the
context it is being called under. It is akin to the test mode or simulate
flag that you see with various utilities. The platform cannot control what
populateDAG does, even without this information, in multiple calls that you
mention the application can return different DAGs by depending on
any external factor such as time of day or some external variable. This is
to merely provide more context information in the config. It is upto the
application to do what it wishes with it.

On Tue, Dec 19, 2017 at 2:28 PM, Vlad Rozov  wrote:


-0.5: populateDAG() may be called by the platform as many times as it
needs (even in case it calls it only once now to launch an application).
Passing different parameters to populateDAG() in simulate launch mode and
actual launch may lead to different DAG being constructed for those two
modes. Can't the use case you described be handled by a plugin?

Thank you,

Vlad


On 12/19/17 10:06, Sanjay Pujare wrote:


+1 although I prefer something that is more enforceable. So I like the
idea
of another method but that introduces incompatibility so may be in 4.0?

On Tue, Dec 19, 2017 at 9:40 AM, Munagala Ramanath <
amberar...@yahoo.com.invalid> wrote:

   +1

Ram
  On Tuesday, December 19, 2017, 8:33:21 AM PST, Pramod Immaneni <
pra...@datatorrent.com> wrote:

   I have a mini proposal. The command get-app-package-info runs the
populateDAG method of an application to construct the DAG but does not
actually launch the DAG. An application developer does not know in

which

context the populateDAG is being called. For example, if they are
recording
application starts in an external system from populateDAG, they will

have

false entries there. This can be solved in different ways such as
introducing another method in StreamingApplication or more parameters
to populateDAG but a non disruptive option would be to add a property

in

the configuration object that is passed to populateDAG to indicate if

it

is
simulate/test mode or real launch. An application developer can use

this

property to take the appropriate actions.

Thanks

[jira] [Commented] (APEXCORE-797) Download page must not link to dist.apache.org

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/APEXCORE-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16299878#comment-16299878
 ] 

Sebb commented on APEXCORE-797:
---

Anyone there?

> Download page must not link to dist.apache.org
> --
>
> Key: APEXCORE-797
> URL: https://issues.apache.org/jira/browse/APEXCORE-797
> Project: Apache Apex Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
>
> The download page currently links to https://dist.apache.org/ for the hashes 
> and sigs.
> However that host is only intended as a staging area for use by developers.
> Please can you change the links to use the ASF webserver instead?
> e.g. change
> https://dist.apache.org/repos/dist/release/apex/apache-apex-core-3.6.0/apache-apex-core-3.6.0-source-release.zip.asc
> to
> https://www.apache.org/dist/apex/apache-apex-core-3.6.0/apache-apex-core-3.6.0-source-release.zip.asc
> etc.
> Also the download page should have a link to the KEYS file:
> https://www.apache.org/dist/apex/KEYS
> And it would be helpful to provide some instructions for using the sigs and 
> hashes:
> https://www.apache.org/dyn/closer.cgi#verify
> Thanks



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)