Re: [RESULT] [VOTE] Move Apex to the Apache Attic

As the project is moving to attic, on the off chance that anybody is still interested in contributing or working on the project, I have setup the repositories under dtpublic https://github.com/dtpublic/apex-core https://github.com/dtpublic/apex-malhar https://github.com/dtpublic/apex-site This

[jira] [Commented] (APEXMALHAR-2566) NPE in FSWindowDataManager

[ https://issues.apache.org/jira/browse/APEXMALHAR-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804597#comment-16804597 ] Pramod Immaneni commented on APEXMALHAR-2566: - [~vikram25] looks like the project

[jira] [Commented] (APEXMALHAR-2566) NPE in FSWindowDataManager

[ https://issues.apache.org/jira/browse/APEXMALHAR-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799364#comment-16799364 ] Pramod Immaneni commented on APEXMALHAR-2566: - java.lang.NullPointerException

[jira] [Created] (APEXMALHAR-2566) NPE in FSWindowDataManager

Pramod Immaneni created APEXMALHAR-2566: --- Summary: NPE in FSWindowDataManager Key: APEXMALHAR-2566 URL: https://issues.apache.org/jira/browse/APEXMALHAR-2566 Project: Apache Apex Malhar

Re: Contribution and committer guidelines

Thanks > Thank you, > > Vlad > > > > On Jan 28, 2019, at 11:58, Pramod Immaneni > wrote: > > > > Amol regarding performance my thoughts were along similar lines but was > > concerned about performance degradation to the real-time path, that new > > change

Re: Contribution and committer guidelines

nt features. I will word is as "do not degrade current > performance > >> significantly". > >> > >> Amol > >> > >> > >> On Fri, Jan 25, 2019 at 9:41 PM Sanjay Pujare > >> wrote: > >> > >>> +1 > >&g

Contribution and committer guidelines

Our contributor and committer guidelines haven't changed in a while. In light of the discussion that happened a few weeks ago, where high commit threshold was cited as one of the factors discouraging submissions, I suggest we discuss some ideas and see if the guidelines should be updated. I have

Re: support Hadoop 3.X

FO] - > >> [INFO] ----- > >> [ERROR] COMPILATION ERROR : > >> [INFO] - > >> [ERROR] >

Re: support Hadoop 3.X

I agree we should just try changing the dependency first. I am in favor of upgrading. It will be good to explore if and how we can leverage some of the new features in 3.x. On Fri, Jan 11, 2019 at 11:38 AM Vlad Rozov wrote: > Hi Aaron, > > I’d recommend to start with upgrading Hadoop dependency

Re: [DISCUSS] Time for attic?

wait 6 months to see if things change. > With > >>>> regards to listing features, that needs to be something that the > >>>> contributors should decide. > >>>> > >>>> Amol > >>>> > >>>> > >&

Re: Salesforce operator

n central and a dependency on a > snapshot version are equally bad and both usually lead to broken builds. > > While protocol may change, API of the connector may change as well, so you > are not well guarded here by using salesforce library, IMO. > > Thank you, > > Vlad >

Re: Salesforce operator

o the shoes of someone who just uses the > binaries > > available here vs. some derivate of former support contract), but putting > > back enhancements and fixes developed as you go would be a good > > step forward. > > > > Thomas > > > > On Wed, Jan 9, 20

Re: [DISCUSS] Time for attic?

We have a couple of operators notably a salesforce operator that I am trying to get the necessary permissions at work to contribute. The underlying salesforce client library (emp-connector) used by the operator doesn't have a release yet so that is another reason slowing things down, waiting to

Re: [DISCUSS] Time for attic?

What would be the purpose of such a vote? From the discussions it is quite apparent that there is a significant, possibly majority view that project shouldn’t go to attic. The same could be reported to the board, can’t it? Like I also said if you or others don’t like where the project is at and

Re: [DISCUSS] Time for attic?

is should go into the next report to the Apache board and all PMCs > (especially those who does not want to move Apex to attic) should prepare > to answer more concerns from the board. > > Thank you, > > Vlad > > > On Jan 8, 2019, at 11:07, Pramod Immaneni > wrot

Re: [DISCUSS] Time for attic?

here's no pressing need to retire it, why do so? > It's possible some enterprise may pick it up and revive it - seems that's > more likely if it's not hidden away in the 'attic'. > -Ilya Ganelin > > > On Mon, Jan 7, 2019 at 8:24 PM Pramod Immaneni > wrote: >

Re: [DISCUSS] Time for attic?

> On Mon, Jan 7, 2019 at 9:50 PM Atri Sharma wrote: > > > >> I agree. > >> > >> The project, IMO, still has hopes for survival since it is well > >> respected for its capabilities. Putting it in attic basically kills it > >> off completely. >

Re: [DISCUSS] Time for attic?

gt; > On Jan 7, 2019, at 12:06, Pramod Immaneni > wrote: > > > > Yes, I have an operator that I am trying to get clearance on before > > submitting. Will likely need a maven server to host a dependency that's > not > > on central. > > > > Thanks > >

Re: [DISCUSS] Time for attic?

Yes, I have an operator that I am trying to get clearance on before submitting. Will likely need a maven server to host a dependency that's not on central. Thanks On Mon, Jan 7, 2019 at 9:08 AM Vlad Rozov wrote: > Does anyone plan to contribute to the project in the near future? > Otherwise, I

[jira] [Commented] (APEXCORE-796) Docker based deployment

[ https://issues.apache.org/jira/browse/APEXCORE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580385#comment-16580385 ] Pramod Immaneni commented on APEXCORE-796: -- We had some community discussions

[jira] [Assigned] (APEXCORE-724) Support for Kubernetes

[ https://issues.apache.org/jira/browse/APEXCORE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni reassigned APEXCORE-724: Assignee: Pramod Immaneni > Support for Kuberne

[jira] [Commented] (APEXMALHAR-2565) Creation of IMDG for data persistence as of now this is handled by In memory , tied to sticky session

[ https://issues.apache.org/jira/browse/APEXMALHAR-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580363#comment-16580363 ] Pramod Immaneni commented on APEXMALHAR-2565: - The in-memory state is checkpointed

[jira] [Commented] (APEXCORE-796) Docker based deployment

[ https://issues.apache.org/jira/browse/APEXCORE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553684#comment-16553684 ] Pramod Immaneni commented on APEXCORE-796: -- Yes, this Jira does not require YARN independence

[jira] [Commented] (APEXCORE-724) Support for Kubernetes

[ https://issues.apache.org/jira/browse/APEXCORE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551024#comment-16551024 ] Pramod Immaneni commented on APEXCORE-724: -- Please see comment on APEXCORE-796 > Supp

[jira] [Commented] (APEXCORE-796) Docker based deployment

[ https://issues.apache.org/jira/browse/APEXCORE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551023#comment-16551023 ] Pramod Immaneni commented on APEXCORE-796: -- I would like to look into this and APEXCORE-724

Re: Branch 3.7.0 failing install related to Kryo version...perhaps

nce sufficient progress is made. > > > > On Wed, Jun 20, 2018 at 2:02 PM Pramod Immaneni < > pramod.imman...@gmail.com> > > wrote: > > > >> That would be awesome, it would be a good use case for the platform. > >> > >> On Wed,

Re: Branch 3.7.0 failing install related to Kryo version...perhaps

t; > +1. Apex does not have as large community as other Apache project, but > > let's try to build it. > > > > Thank you, > > > > Vlad > > > > On 6/20/18 10:24, Pramod Immaneni wrote: > > > Aaron, > > > > > > Your concerns are l

Re: Branch 3.7.0 failing install related to Kryo version...perhaps

e of the project? I really like the > framework and definitely would prefer to use it as well as contribute > back...just want to make sure I am not going to have work on it solo or > worse, end up having to switch to something else later... > > Your thoughts? > > Aaron >

Re: Branch 3.7.0 failing install related to Kryo version...perhaps

> > On 6/20/18 09:09, Pramod Immaneni wrote: > > There are hadoop IPC calls are failing possibly because of its reliance > on > > kryo for serializing the payload and there is some incompatibility with > the > > new version. I will dig in more to see what is goin

Re: Branch 3.7.0 failing install related to Kryo version...perhaps

There are hadoop IPC calls are failing possibly because of its reliance on kryo for serializing the payload and there is some incompatibility with the new version. I will dig in more to see what is going on. On Tue, Jun 19, 2018 at 6:54 PM Aaron Bossert wrote: > Pramod, > > Thanks for taking

Re: Kryo version and default serializer

IMHO...though I understand that is > > something of a lift. By the way, Kryo 5 just came out yesterday, so if > > there is to be effort expended, it might be good to go with the latest > > version...though, heads up, I tried it out and there seem to be quite a > few > > changes that

Re: Kryo version and default serializer

t; the errors were different... >> >> Sent from my iPhone >> >> On Jun 11, 2018, at 15:11, Pramod Immaneni >> wrote: >> >> Aaron, >> >> The question might be best served on the dev@apex.apache.org mailing >> list as you are starting to make

[jira] [Commented] (APEXCORE-817) StramLocalCluster.testDynamicLoading test failing on travis

[ https://issues.apache.org/jira/browse/APEXCORE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517710#comment-16517710 ] Pramod Immaneni commented on APEXCORE-817: -- The test is failing because of a higher major

[jira] [Created] (APEXCORE-817) StramLocalCluster.testDynamicLoading test failing on travis

Pramod Immaneni created APEXCORE-817: Summary: StramLocalCluster.testDynamicLoading test failing on travis Key: APEXCORE-817 URL: https://issues.apache.org/jira/browse/APEXCORE-817 Project

[jira] [Resolved] (APEXCORE-807) In secure mode containers are failing after one day and the application is failing after seven days

[ https://issues.apache.org/jira/browse/APEXCORE-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni resolved APEXCORE-807. -- Resolution: Fixed Fix Version/s: 4.0.0 > In secure mode contain

Re: Branch 3.7.0 failing install related to Kryo version...perhaps

Do you see the same errors when you run the individual tests in question in isolation, such as using mvn test -Dtest=. If you do can you paste the full logs of what you see when the individual tests fail. Thanks On Mon, Jun 18, 2018 at 11:41 AM Aaron Bossert wrote: > please disregard the first

Re: Proposal for UI component in stram

ike this. > >>> > >>> 1. We develop the wrapper UI for apexCli in the first phase and > give > >>> user all the management options as REST APIs. > >>> 2. If some of information we require are not in the current apexCli > >>>

Re: Proposal for UI component in stram

I too think that a comprehensive UI works better standalone but given that stram already runs a webapp server, provides web services and RM provides a proxy with mapped url space for it, we can extend stram to provide better visual output. Overall I am +1 on the idea. On Mon, Jun 11, 2018 at 8:59

Re: [ANNOUNCE] New Apache Apex PMC Member: Chinmay Kolhatkar

Congratulations Chinmay. On Thu, May 24, 2018 at 9:39 AM Thomas Weise wrote: > The Apache Apex PMC is pleased to announce that Chinmay Kolhatkar is now a > PMC member. > > Chinmay has contributed to Apex in many ways, including: > > - Various transform operators in Malhar > -

Re: project dependencies - important

gt; R has an example, so we might want to find a way to keep that alive. >> >> >> On Wed, May 2, 2018 at 7:33 PM, Pramod Immaneni <pra...@datatorrent.com> >> wrote: >> >> I see a kafka 0.7.1. Not sure if it is still being used. >>> >>>

Re: project dependencies - important

er R and zmq, anything else? > > Thanks, > Thomas > > > On Wed, May 2, 2018 at 6:53 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > Hello Community, > > > > As you may know, DataTorrent was the original developer and initial > >

project dependencies - important

Hello Community, As you may know, DataTorrent was the original developer and initial contributor of Apex. There are a couple of dependencies the project still has on DataTorrent. One of them is the project netlet, hosted in DataTorrent github, that provides a networking library for data

[ANNOUNCE] Apache Apex Core 3.7.0 released

Dear Community, The Apache Apex community is pleased to announce release 3.7.0 of Apex Core (the engine). Apache Apex is an enterprise-grade big data-in-motion platform that unifies stream and batch processing. Apex was built for scalability and low-latency processing, high availability and

Re: [RESULT] [VOTE] Apache Apex Core Release 3.7.0 (RC1)

Yes Thomas will complete it in a day or two. Thanks On Tue, Apr 24, 2018 at 9:15 AM, Thomas Weise <t...@apache.org> wrote: > Hi Pramod, > > Are you going to complete the release? > > Thanks > > > On Wed, Apr 18, 2018 at 9:31 PM, Pramod Immaneni <pra...@datator

[jira] [Created] (APEXCORE-810) Concurrent modification exception during connection cleanup in buffer server

Pramod Immaneni created APEXCORE-810: Summary: Concurrent modification exception during connection cleanup in buffer server Key: APEXCORE-810 URL: https://issues.apache.org/jira/browse/APEXCORE-810

[RESULT] [VOTE] Apache Apex Core Release 3.7.0 (RC1)

> - verified signatures > - build from source archive > - tests pass > - run pi demo on YARN 2.7.1 > > When updating the download page after the release, please also remove the > md5 links from it. > > Thanks, > Thomas > > > On Sat, Apr 14, 2018 at 11:48 A

[jira] [Created] (APEXCORE-809) Documentation does not build with current versions (8.11.x) of nodejs

Pramod Immaneni created APEXCORE-809: Summary: Documentation does not build with current versions (8.11.x) of nodejs Key: APEXCORE-809 URL: https://issues.apache.org/jira/browse/APEXCORE-809

[jira] [Created] (APEXCORE-808) Change min supported java version dependency to Java 8

Pramod Immaneni created APEXCORE-808: Summary: Change min supported java version dependency to Java 8 Key: APEXCORE-808 URL: https://issues.apache.org/jira/browse/APEXCORE-808 Project: Apache Apex

[jira] [Updated] (APEXCORE-807) In secure mode containers are failing after one day and the application is failing after seven days

[ https://issues.apache.org/jira/browse/APEXCORE-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni updated APEXCORE-807: - Issue Type: Bug (was: Task) > In secure mode containers are failing after one

[jira] [Commented] (APEXCORE-807) In secure mode containers are failing after one day and the application is failing after seven days

[ https://issues.apache.org/jira/browse/APEXCORE-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442548#comment-16442548 ] Pramod Immaneni commented on APEXCORE-807: -- This is happening because the tokens are not being

[jira] [Created] (APEXCORE-807) In secure mode tokens containers are failing after one day and the application is failing after seven days

Pramod Immaneni created APEXCORE-807: Summary: In secure mode tokens containers are failing after one day and the application is failing after seven days Key: APEXCORE-807 URL: https://issues.apache.org/jira

[jira] [Updated] (APEXCORE-807) In secure mode containers are failing after one day and the application is failing after seven days

[ https://issues.apache.org/jira/browse/APEXCORE-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni updated APEXCORE-807: - Summary: In secure mode containers are failing after one day and the application

Re: Core release 3.7.0

Updated master to 4.0.0-SNAPSHOT. On Wed, Apr 11, 2018 at 5:04 PM, Pramod Immaneni <pra...@datatorrent.com> wrote: > Will move this one to 4.0 > > On Mon, Apr 9, 2018 at 11:19 AM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > >> Can this be moved to t

Re: [VOTE] Apache Apex Core Release 3.7.0 (RC1)

Dear community, Please verify and vote. Thanks On Sun, Apr 15, 2018 at 8:45 AM, Pramod Immaneni <pra...@datatorrent.com> wrote: > Hi, > > Regd [4][5], these are templates used to generate a base application > project for users to modify and use when they run the maven archet

Re: [VOTE] Apache Apex Core Release 3.7.0 (RC1)

.gz' > gpg: Signature made Sun 15 Apr 01:21:20 2018 AEST > gpg:using RSA key EB4B068AE51B20BFA40FDAA779480420239E728D > gpg: requesting key 79480420239E728D from hkps server > hkps.pool.sks-keyservers.net > gpg: key 79480420239E728D: public key "Pram

Re: [VOTE] Apache Apex Core Release 3.7.0 (RC1)

The old key was not used at all. > On Apr 14, 2018, at 3:32 PM, Vlad Rozov <vro...@apache.org> wrote: > > Please fix the KEYS before proceeding with the vote. > > Thank you, > > Vlad > >> On 4/14/18 11:48, Pramod Immaneni wrote: >> Dear Community,

[VOTE] Apache Apex Core Release 3.7.0 (RC1)

Dear Community, Please vote on the following Apache Apex Core 3.7.0 release candidate. This is a source release with binary artifacts published to Maven. List of all issues fixed: https://s.apache.org/fWT8 User documentation: https://apex.apache.org/docs/apex-3.7/ Staging directory:

[jira] [Updated] (APEXCORE-755) Deprecate dt.* properties and make them available with apex. keys

[ https://issues.apache.org/jira/browse/APEXCORE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni updated APEXCORE-755: - Fix Version/s: (was: 3.7.0) 4.0.0 > Deprecate dt.* propert

Re: Core release 3.7.0

Will move this one to 4.0 On Mon, Apr 9, 2018 at 11:19 AM, Pramod Immaneni <pra...@datatorrent.com> wrote: > Can this be moved to the next release as it is not done > > https://issues.apache.org/jira/browse/APEXCORE-755 > > On Mon, Apr 9, 2018 at 8:32 AM, Pramod Immaneni &l

Re: Core release 3.7.0

hould only be added (as described above), > not removed. > > > > > > On 4/9/18 16:13, Pramod Immaneni wrote: > >> I lost my gpg key and had to generate a new one, folks please sign it when >> you can. >> >> http://pgp.mit.edu/pks/lookup?op=get=0x7948042023

Re: Core release 3.7.0

re is no branch created for *release versions* though. > > +1 for major version change > > On Mon, Apr 9, 2018 at 2:36 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > git branch -a | grep release > > > > remotes/origin/release-3.0 > >

Re: Core release 3.7.0

://apex.apache.org/release.html Thanks On Mon, Apr 9, 2018 at 1:45 PM, Vlad Rozov <vro...@apache.org> wrote: > What was the reason to create the branch? Usually there is no branch > created, only tag. > > Thank you, > > Vlad > > > On 4/9/18 08:32, Pramod Immaneni wrote: >

Re: Core release 3.7.0

Also, since we will be changing min jdk version to 8 for next release, I am fine with thomas's suggestion to change next version to 4.0. If there are no objections I will update the version on master. Thanks On Mon, Apr 9, 2018 at 11:19 AM, Pramod Immaneni <pra...@datatorrent.com> wrote:

Re: Core release 3.7.0

Can this be moved to the next release as it is not done https://issues.apache.org/jira/browse/APEXCORE-755 On Mon, Apr 9, 2018 at 8:32 AM, Pramod Immaneni <pra...@datatorrent.com> wrote: > The branch release-3.7 has been created and master changed to > 3.8.0-SNAPSHOT. > > O

Re: Core release 3.7.0

The branch release-3.7 has been created and master changed to 3.8.0-SNAPSHOT. On Fri, Apr 6, 2018 at 1:03 PM, Pramod Immaneni <pra...@datatorrent.com> wrote: > Now that this has been merged, I will cut the release branch over the > weekend. > > Thanks > > On Fri, Mar 23,

Re: Core release 3.7.0

Now that this has been merged, I will cut the release branch over the weekend. Thanks On Fri, Mar 23, 2018 at 12:49 PM, Thomas Weise <t...@apache.org> wrote: > https://github.com/apache/apex-core/pull/583 > > > On Thu, Mar 22, 2018 at 1:47 PM, Pramod Immaneni <pra...@dat

[jira] [Resolved] (APEXCORE-789) Update security doc to describe the impact of SSL enablement on truststores

[ https://issues.apache.org/jira/browse/APEXCORE-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni resolved APEXCORE-789. -- Resolution: Fixed Fix Version/s: 3.7.0 > Update security doc to descr

Re: Core release 3.7.0

Is there anything folks would want to get merged before the release process starts. Remember this would be the last release supporting Java 7. Thanks On Sat, Feb 24, 2018 at 5:16 AM, Pramod Immaneni <pra...@datatorrent.com> wrote: > ok > > On Mon, Feb 19, 2018 at 1:30 PM,

Re: Core release 3.7.0

ok On Mon, Feb 19, 2018 at 1:30 PM, Thomas Weise <t...@apache.org> wrote: > I think that should be done after the release, along with 4.x version > change. > > > On Mon, Feb 19, 2018 at 10:06 AM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > Sh

Re: Core release 3.7.0

Shall we move to Java 8 with this release On Wed, Jan 31, 2018 at 9:06 AM, Pramod Immaneni <pra...@datatorrent.com> wrote: > I can do it if no one is volunteering. > > Thanks > > > On Jan 31, 2018, at 7:59 AM, Thomas Weise <t...@apache.org> wrote: > > >

Re: [Proposal] Extension of the Apex configuration to add dependent jar files in runtime.

only. > > Thank you, > > Vlad > > On 2/3/18 09:13, Pramod Immaneni wrote: >> I too agree that the discussion has veered off from the original topic. Why >> can't LIBRARY_JARS be used for this, albeit with a minor improvement? >> Currently, our attribut

Re: [Proposal] Extension of the Apex configuration to add dependent jar files in runtime.

I too agree that the discussion has veered off from the original topic. Why can't LIBRARY_JARS be used for this, albeit with a minor improvement? Currently, our attribute layering is an override, so if you have an attribute that is specified as apex.application..attr. it overrides apex.attr. for

Re: Core release 3.7.0

gt;>> >>>>> +1 for the release >>>>>> >>>>>> Regards, >>>>>> - Tushar. >>>>>> >>>>>> >>>>>> On Thu, Jan 18, 2018 at 3:28 AM, Amol Kekre <a...@datatorrent.com> >>

[jira] [Created] (APEXCORE-804) Setting to let application know when DAG is not being created for launch

Pramod Immaneni created APEXCORE-804: Summary: Setting to let application know when DAG is not being created for launch Key: APEXCORE-804 URL: https://issues.apache.org/jira/browse/APEXCORE-804

Re: [Proposal] Switch to Java 8

port for Java 8 is dropped. > > Thank you, > > Vlad > > On 1/19/18 11:36, Sanjay Pujare wrote: >> Are they mutually exclusive? Otherwise "start supporting Java 9" doesn't >> have to imply stopping Java 8 support. I think Vlad implied supporting both. >&g

Re: [Proposal] Switch to Java 8

Java 9 will shut people out as 8 is not yet eol. The majority of the installations I have seen are running 8 and people are moving from 7 to 8. Other projects in our space are also moving to 8. > On Jan 19, 2018, at 8:31 AM, Vlad Rozov wrote: > > +1. It will be good to

Re: Core release 3.7.0

+1 > On Jan 17, 2018, at 7:25 AM, Thomas Weise wrote: > > Last release was 3.6.0 in May and following issues are ready for release: > > https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%203.7.0%20AND%20project%20%3D%20APEXCORE%20ORDER%20BY%20status%20ASC > > Any

Re: [Proposal] Simulate setting for application launch

y care what DAG is returned. It does not enforce nor rely that DAGs returned by multiple calls to populateDAG be the same DAG. > > Thank you, > > Vlad > > > On 12/21/17 10:05, Pramod Immaneni wrote: > >> Asking users to create plugins for something they want

Re: [Proposal] Simulate setting for application launch

t; > > > > > 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 > >&

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

[ 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 depende

Re: [Proposal] Simulate setting for application launch

ad > > > 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, 201

Re: [Discuss] Design of the python execution operator

ted to take the approach of a worker > pool. > > > Yes your point is valid if we wait for the stragglers to complete in a > > > given window. The current implementation does not force to wait for all > > of > > > the stragglers to complete. The stragglers are e

Re: [Proposal] Simulate setting for application launch

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

[Proposal] Simulate setting for application launch

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

Re: [Discuss] Design of the python execution operator

rt is > emitting the result for a request submitted in the previous window. This > also implies that idempotency cannot be guaranteed across runs of the same > input data. In fact all threaded implementations have this issue as > ordering of the results is not guaranteed to be unique even wit

Re: [Discuss] Design of the python execution operator

Hi Anath, Sounds interesting and looks like you have put quite a bit of work on it. Might I suggest changing the title of 2260 to better fit your proposal and implementation, mainly so that there is differentiation from 2261. I wanted to discuss the proposal to use multiple threads in an

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

Pramod Immaneni created APEXCORE-801: Summary: Committer guidelines for dependency CVE failures Key: APEXCORE-801 URL: https://issues.apache.org/jira/browse/APEXCORE-801 Project: Apache Apex Core

[jira] [Resolved] (APEXCORE-790) Enforce dependency analysis for CVE in CI builds

[ https://issues.apache.org/jira/browse/APEXCORE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni resolved APEXCORE-790. -- Resolution: Fixed Fix Version/s: 3.7.0 > Enforce dependency analysis for

[ANNOUNCE] New Apache Apex PMC: Tushar Gosavi

A bit delayed but nevertheless important announcement, Apache Apex PMC is pleased to announce Tushar Gosavi as a new PMC member. Tushar has been contributing to Apex from the beginning of the project and has been working on the codebase for over 3 years. He is among the few who have a wide

Re: checking dependencies for known vulnerabilities

gt; > > On Thu, Nov 2, 2017 at 11:35 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > If the PR introduces a CVE by all means lets fail it initally and later > > look at whitelisting it if needed. Why fail all PRs that haven't caused > the > > probl

Re: checking dependencies for known vulnerabilities

; subsequent releases as well as a set of artefacts in the project modules > that summarise the community’s awareness of the issue. > > > Regards > Ananth > > > On 3 Nov 2017, at 8:38 am, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > > The question is wh

Re: checking dependencies for known vulnerabilities

cal behavior, unless the CI build fails, very few will > be > >> interested fixing the issues. > >> > >> Perhaps if after a CI failure the issue can be identified as > pre-existing, > >> we can whitelist and create a JIRA that must be addressed prior to

Re: Malhar release 3.8.0

t is also possible to consider entire library as optional, somebody may > use only one operator from the entire library. > > Thank you, > > Vlad > > > On 11/1/17 12:49, Pramod Immaneni wrote: > >> I was thinking of it more in terms of optional that Justin mentioned >> e

Re: Malhar release 3.8.0

egards, > Ananth > > > > On 2 Nov 2017, at 6:10 am, Vlad Rozov <vro...@apache.org> wrote: > > > > It does not matter whether sql (and demos) is part of the main profile > or not. It is a source release, not a binary release and source includes > all profi

Re: checking dependencies for known vulnerabilities

gt; On 11/1/17 11:39, Pramod Immaneni wrote: > >> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vro...@apache.org> wrote: >> >> There is no independent build and the check is still necessary to prevent >>> new dependencies with CVE being introduced. >>>

Re: Malhar release 3.8.0

rce includes all > profiles. > > Thank you, > > Vlad > > > On 11/1/17 11:50, Pramod Immaneni wrote: > >> Vlad can you add this command to the release instructions and the >> committer >> guidelines. If we are unable to address this for this releas

Re: Malhar release 3.8.0

_ >>>>>>> >>>>>>> Bhupesh Chawda >>>>>>> >>>>>>> E: bhup...@datatorrent.com | Twitter: @bhupeshsc >>>>>>> >>>>>>> www.datatorrent.com | apex.apache.org >>>>&

Re: checking dependencies for known vulnerabilities

d in PRs. I am not against adding additional checks that verify the PR better. > > Thank you, > > Vlad > > > On 11/1/17 11:21, Pramod Immaneni wrote: > >> My original concern still remains. I think what you have is valuable but >> would prefer that it be activat

Re: checking dependencies for known vulnerabilities

guing that premise. I don't think we should bring regular development to a halt whenever a matching CVE is discovered, unless there is some other secondary reason like merging a PR will make it difficult for a CVE fix to be made. Have you given a thought to what I said about having a separate build that will n

Re: checking dependencies for known vulnerabilities

On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov <vro...@apache.org> wrote: > On 10/26/17 11:46, Pramod Immaneni wrote: > >> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vro...@apache.org> wrote: >> >> I guess you are mostly concerned regarding new CVE in an ex

  1   2   3   4   5   >