Re: [PROPOSAL] Weave for Apache Incubator

[Vinod Kumar Vavilapalli]

I mentioned this offline to others too.

We've had lots of discussions in the past about contrib projects overall in 
Hadoop and we moved away from there.

The same started happening with YARN, and we took a stand that YARN shouldn't 
run into the same umbrella issue. You can see the JIRA discussions on Paas On 
YARN etc for more context.

As for Weave, it represents a good programming model (threads) alongside MR and 
so deserves its own home IMO.

Thanks,
+Vinod

On Nov 3, 2013, at 11:21 PM, Roman Shaposhnik wrote:

> Have you guys considered contributing this code directly to Hadoop?
> 
> From what you are describing it sounds like a developer friendly library
> wrapped around YARN (along the lines of kitten:
> https://github.com/jwills/kitten).
> 
> 
> Thanks,
> Roman.
> 
> On Tue, Oct 29, 2013 at 12:53 PM, Andreas Neumann  wrote:
>> I would like to propose Weave, an abstraction over Apache Hadoop® YARN to
>> reduce the complexity of developing distributed applications, as an
>> Apache Incubator
>> podling.
>> 
>> The proposal is included in plain text. I would also like to put this on
>> the wiki, but I appear to lack privileges to create pages. What do I need
>> to do to get permission?
>> 
>> -Andreas.
>> 
>> Abstract
>> 
>> 
>> Weave is an abstraction over Apache Hadoop® YARN that reduces the
>> complexity of developing distributed applications, allowing developers to
>> focus more on their business logic.
>> 
>> Proposal
>> 
>> 
>> Weave is a set of libraries that reduces the complexity of developing
>> distributed applications. It exposes the distributed capabilities of Apache
>> Hadoop® YARN via a simple and intuitive programming model similar to Java
>> threads. Weave also has built-in capabilities required by many distributed
>> applications, such as real-time application logs and metrics collection,
>> application lifecycle management, and network service discovery.
>> 
>> Background
>> ==
>> 
>> Hadoop YARN is a generic cluster resource manager that supports any type of
>> distributed application. However, YARN’s interfaces are too low level for
>> rapid application development. It requires a great deal of boilerplate code
>> even for a simple application, creating a high ramp up cost that can turn
>> developers away.
>> 
>> Weave is designed to improve this situation with a programming model that
>> makes running distributed applications as easy as running Java threads.
>> With the abstraction provided by Weave, applications can be executed in
>> process threads during development and unit testing and then be deployed to
>> a YARN cluster without any modifications.
>> 
>> Weave also has built-in support for real-time application logs and metrics
>> collection, delegation token renewal, application lifecycle management, and
>> network service discovery. This greatly reduces the pain that developers
>> face when developing, debugging, deploying and monitoring distributed
>> applications.
>> 
>> Weave is not a replacement for YARN, it’s a framework that operates on top
>> of YARN.
>> 
>> Rationale
>> =
>> 
>> Developers who write YARN applications typically find themselves
>> implementing the same (or similar) boilerplate code over and over again for
>> every application. It makes sense to distill this common code into a
>> reusable set of libraries that is perpetually maintained and improved by a
>> diverse community of developers.
>> 
>> Weave’s simple thread-like programming model will enable many Java
>> programmers to develop distributed applications. We believe that this
>> simplicity will attract developers who would otherwise be discouraged by
>> complexity, and many new use cases will emerge for the usage of YARN.
>> 
>> Incubating Weave as an Apache project makes sense because Weave is a
>> framework built on top of YARN, and Weave uses Apache Zookeeper, HDFS,
>> Kafka, and other Apache software (see the External Dependencies section).
>> 
>> Current Status
>> ==
>> 
>> Weave was initially developed at Continuuity. The Weave codebase is
>> currently hosted in a public repository at github.com, which will seed the
>> Apache git repository.
>> 
>> Meritocracy
>> ---
>> Our intent with this incubator proposal is to start building a diverse
>> developer community around Weave following the Apache meritocracy model.
>> Since Weave was initially developed in early 2013, we have had fast
>> adoption and contributions within Continuuity. We are looking forward to
>> new contributors. We wish to build a community based on Apache's
>> meritocracy principles, working with those who contribute significantly to
>> the project and welcoming them to be committers both during the incubation
>> process and beyond.
>> 
>> Community
>> -
>> Weave is currently being used internally at Continuuity and is at the core
>> of our products. We hope to extend our contributor base significantly and
>> we will invite all who are interested in simplifyin

Re: [VOTE] Accept Twill for Incubation

[Vinod Kumar Vavilapalli]

+1

Thanks,
+Vinod

On Nov 7, 2013, at 1:04 PM, Andreas Neumann wrote:

> The discussion about the Weave proposal has calmed. As the outcome of the
> discussion, we have chosen a new name for the project, Twill. I would like
> to call a vote for Twill to become an incubated project.
> 
> The proposal is pasted below, and also available at:
> https://wiki.apache.org/incubator/TwillProposal
> 
> Let's keep this vote open for three business days, closing the voting on
> Tuesday 11/12.
> 
> [ ] +1 Accept Twill into the Incubator
> [ ] +0 Don't care.
> [ ] -1 Don't accept Twill because...
> 
> -Andreas.
> 
> = Abstract =
> 
> Twill is an abstraction over Apache Hadoop® YARN that reduces the
> complexity of developing distributed applications, allowing developers to
> focus more on their business logic.
> 
> = Proposal =
> 
> Twill is a set of libraries that reduces the complexity of developing
> distributed applications. It exposes the distributed capabilities of Apache
> Hadoop® YARN via a simple and intuitive programming model similar to Java
> threads. Twill also has built-in capabilities required by many distributed
> applications, such as real-time application logs and metrics collection,
> application lifecycle management, and network service discovery.
> 
> = Background =
> 
> Hadoop YARN is a generic cluster resource manager that supports any type of
> distributed application. However, YARN’s interfaces are too low level for
> rapid application development. It requires a great deal of boilerplate code
> even for a simple application, creating a high ramp up cost that can turn
> developers away.
> 
> Twill is designed to improve this situation with a programming model that
> makes running distributed applications as easy as running Java threads.
> With the abstraction provided by Twill, applications can be executed in
> process threads during development and unit testing and then be deployed to
> a YARN cluster without any modifications.
> 
> Twill also has built-in support for real-time application logs and metrics
> collection, delegation token renewal, application lifecycle management, and
> network service discovery. This greatly reduces the pain that developers
> face when developing, debugging, deploying and monitoring distributed
> applications.
> 
> Twill is not a replacement for YARN, it’s a framework that operates on top
> of YARN.
> 
> = Rationale =
> 
> Developers who write YARN applications typically find themselves
> implementing the same (or similar) boilerplate code over and over again
> for every application. It makes sense to distill this common code into a
> reusable set of libraries that is perpetually maintained and improved by a
> diverse community of developers.
> 
> Twill’s simple thread-like programming model will enable many Java
> programmers to develop distributed applications. We believe that this
> simplicity will attract developers who would otherwise be discouraged by
> complexity, and many new use cases will emerge for the usage of YARN.
> 
> Incubating Twill as an Apache project makes sense because Twill is a
> framework built on top of YARN, and Twill uses Apache Zookeeper, HDFS,
> Kafka, and other Apache software (see the External Dependencies section).
> 
> = Current Status =
> 
> Twill was initially developed at Continuuity under the name of Weave. The
> Weave codebase is currently hosted in a public repository at github.com,
> which will seed the Apache git repository after renaming to Twill.
> 
> == Meritocracy ==
> 
> Our intent with this incubator proposal is to start building a diverse
> developer community around Twill following the Apache meritocracy model.
> Since Twill was initially developed in early 2013, we have had fast
> adoption and contributions within Continuuity. We are looking forward to
> new contributors. We wish to build a community based on Apache's
> meritocracy principles, working with those who contribute significantly to
> the project and welcoming them to be committers both during the incubation
> process and beyond.
> 
> == Community ==
> 
> Twill is currently being used internally at Continuuity and is at the core
> of our products. We hope to extend our contributor base significantly and
> we will invite all who are interested in simplifying the development of
> distributed applications to participate.
> 
> == Core Developers ==
> 
> Twill is currently being developed by five engineers at Continuuity:
> Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert
> Shau.
> Terence Yim is an Apache committer for Helix, Andreas is an Apache
> committer and PMC member for Oozie, and Gary Helmling is an Apache
> committer and PMC member for HBase. Poorna Chandra and Albert Shau have
> made many contributions to Twill.
> 
> == Alignment ==
> 
> The ASF is the natural choice to host the Twill project as its goal of
> encouraging community-driven open source projects fits with our vision for
> Twill.
> 
> Additionally, many other pro

Re: [VOTE] Accept Slider into the incubator

[Vinod Kumar Vavilapalli]

Tx Chip/Suresh. I'd join IPMC if needed.

+Vinod

On Apr 17, 2014, at 6:52 AM, Chip Childers  wrote:

> On Thu, Apr 17, 2014 at 9:36 AM, Suresh Marru  wrote:
>> Champion on this proposal Vinod Kumar Vavilapalli doesn't seem to be on the
>> IPMC but since he is a member its just a customary to ask and get inducted.
>> 
>> Can this be addressed?
> 
> As I read [1], thats only really necessary if he wants to be a mentor.
> However, as you point out, it's trivial for Vinod to join the IPMC,
> since he's a member.
> 
> -chip
> 
> [1] 
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.


signature.asc
Description: Message signed with OpenPGP using GPGMail

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Slider into the incubator

[Vinod Kumar Vavilapalli]

This is a great addition to the Hadoop YARN ecosystem.

Hoping the name doesn't conflict with any existing software, here's my +1.

Thanks,
+Vinod

On Apr 17, 2014, at 6:01 AM, Steve Loughran  wrote:

> I'd like to call a vote on accepting Slider into the incubator
> 
> 
> https://wiki.apache.org/incubator/SliderProposal
> 
> [ ] +1 Accept Slider into the Incubator
> [ ] +0 Indifferent to the acceptance of Slider
> [ ] -1 Do not accept Slider because …
> 
> 
> The vote will be open until Thursday April 24 13:00 UTC
> 
> -Steve
> 
> -- 
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to 
> which it is addressed and may contain information that is confidential, 
> privileged and exempt from disclosure under applicable law. If the reader 
> of this message is not the intended recipient, you are hereby notified that 
> any printing, copying, dissemination, distribution, disclosure or 
> forwarding of this communication is strictly prohibited. If you have 
> received this communication in error, please contact the sender immediately 
> and delete it from your system. Thank You.


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.


signature.asc
Description: Message signed with OpenPGP using GPGMail

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Tez graduation [Was: Request for mentor assessment]

[Vinod Kumar Vavilapalli]

It looks like this page was indeed not up to date as I heard that it was up to 
the individual committers involved to add themselves to that page and some or 
more of them didn't do it. If there is a way to figure out the official list 
instead of depending on this page, that should address some concerns. In the 
mean while, one of us can tip them off to get the page updated.

Thanks
+Vinod

On Jun 21, 2014, at 10:18 PM, Henry Saputra  wrote:

> Looks like the page is not updated because the proposal mentions more
> diverse people [1]
> 
> [1] http://wiki.apache.org/incubator/TezProposal
> 
> On Fri, Jun 20, 2014 at 8:02 PM, Konstantin Boudnik  wrote:
>> Ok, I've reached out to the Tez project and it seems that they are wokring w/
>> Chris Mattmann's on the graduation process (per an email exchange
>> http://s.apache.org/K7g). What has caught my attention is the PPMC 
>> composition
>> which is pretty much uniformly represented by a group with the same
>> affiliation. Given that this page 
>> https://tez.incubator.apache.org/team-list.html
>> is up to date.
>> 
>> If I am reading https://incubator.apache.org/guides/graduation.html#community
>> right, the PPMC and committers composition should be diversified. Is it a
>> concern for graduation from the IPMC standpoint of view?
>> 
>> Regards,
>>  Cos
>> 
>> On Mon, Jun 16, 2014 at 06:54PM, Chris Douglas wrote:
>>> Tez is ready to graduate. Cos, if you can help us manage that process,
>>> it'd certainly be appreciated. -C
>>> 
>>> On Mon, Jun 16, 2014 at 12:53 PM, Konstantin Boudnik  
>>> wrote:
 I share the sentiment with NPanday - doesn't seem like anything is 
 happening
 there really.
 
 If it of an interest to the incubator, I will volunteer to help mentoring 
 Tez.
 
 Cos
 
 
 On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote:
> I think Tez needs some more help mentoring. I myself haven't had
> as much time as possible so the more folks over there that can
> help mentor the better.
> 
> Good job starting this thread, Roman.
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Roman Shaposhnik 
> Reply-To: "general@incubator.apache.org" 
> Date: Thursday, June 12, 2014 5:44 PM
> To: "general@incubator.apache.org" 
> Subject: Re: Request for mentor assessment
> 
>> On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra 
>> wrote:
>>> Seems like NPanday should go to attic. One mentor I asked did not even
>>> monitor it anymore
>> 
>> I've had exactly the same experience. My plan here is to wait for folks
>> to chime in on this thread and for those mentors who are MiA start
>> different threads asking for additional (replacement) mentors.
>> 
>> I really would like for things like retirement proposals to come from
>> somebody who's spent time getting to know the community in greater
>> details.
>> 
>> Thanks,
>> Roman.
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.


signature.asc
Description: Message signed with OpenPGP using GPGMail

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubat

Re: Tez graduation [Was: Request for mentor assessment]

[Vinod Kumar Vavilapalli]

I see two threads here
 - Concerns about graduation of Apache Tez project w.r.t diversity based on the 
PPMC html page
 - Community related threads about things like whether diversity is a hard 
requirement or how to grow communities.

AFAICT, Hitesh's latest information on the state of the members of the team 
(and the updated page) should allay any concerns on diversity.

If people disagree, we can continue this thread along that discussion. If not, 
we can close this topic as the graduation discussion/vote proceeds here and 
elsewhere.

The other threads may be valuable but OT IMHO and so are better forked into 
their own threads.

Thanks,
+Vinod

On Jun 23, 2014, at 4:26 PM, Roman Shaposhnik  wrote:

> On Mon, Jun 23, 2014 at 2:41 PM, Ted Dunning  wrote:
>> On Mon, Jun 23, 2014 at 2:23 PM, Bikas Saha  wrote:
>> 
>>> Community building is an organic process that grows on its own accord.
>>> 
>> 
>> Really, I was going to run away for a bit, but my feeling is that this
>> statement is amazingly naive about how communities are built.
>> 
>> Community doesn't just happen.  Community doesn't just grow of its own
>> accord.  Community grows when people make serious, explicit actions to help
>> it grow, to bring in newcomers, to publish plans in many places *before*
>> code is written.
>> 
>> Building community is hard work that you have to intend to do.  If you
>> don't do the work, it won't just happen any more than code writes itself.\
> 
> +infinity to that!
> 
> And in fact, I think this is the crux of this very discussion: as part
> of the graduation criteria an incubating project needs to demonstrate
> that they have understood and mastered that art.  At the end of the
> day the passing grade for incubating is based on that very criteria:
> can a project demonstrate that if allowed to the TLP status it will
> not let its community wane.
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.


signature.asc
Description: Message signed with OpenPGP using GPGMail

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Joining IPMC

[Vinod Kumar Vavilapalli]

Hi,

I would like to get on to IPMC so that I can help mentor some of the
incubator projects. I am already an ASF member and also championing the
Slider project.

Let me know how I can move forward with this.

Thanks,
+Vinod


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [ANNOUNCE] Vinod Kumar Vavilapalli joins the IPMC

[Vinod Kumar Vavilapalli]

Thanks!

Will do.

Tx
+Vinod

On Thu, Jul 3, 2014 at 10:07 AM, Roman Shaposhnik  wrote:

> Hi!
>
> an ASF member Vinod Kumar Vavilapalli has
> volunteered recently to join the Incubator PMC.
>
> Welcome, Vinod! Great to have you on board!
>
> Please make sure to subscribed yourself to the
> IPMC MLs and also feel free to let us know a
> surprising thing or two about yourself ;-)
>
> Thanks,
> Roman.
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [VOTE] Release Apache Tez-0.4.1-incubating RC0

[Vinod Kumar Vavilapalli]

I checked this RC, based on my check-list:

 - Signatures and message digests are good.
 - The LICENSE, NOTICE, DISCLAIMER and README for the source artifact are
all good
 - CHANGES.txt is good.
 - Able to build the tars out of the source tar ball.

Here's my +1 (binding) for the latest RC.

Thanks,
Vinod

On Mon, Jul 7, 2014 at 1:20 PM, Siddharth Seth  wrote:

> The Apache Tez Incubating PPMC has voted to release Apache
> Tez-0.4.1-incubating (RC0).
>
> Result Mail:
>
> http://mail-archives.apache.org/mod_mbox/incubator-tez-dev/201407.mbox/%3CCAOapipsBOizkB5yOmCxT1UP9%2BCL%2BHjtxcy39mzFNFkZXeocaxA%40mail.gmail.com%3E
> Initial Vote Thread:
>
> http://mail-archives.apache.org/mod_mbox/incubator-tez-dev/201406.mbox/%3CCAOapipsP5KfMD2_imfubp%2BUKc9qPA5b4EVAmRPqbv-utt%3DSNkQ%40mail.gmail.com%3E
>
> This thread is for the IPMC to vote on this release.
>
> GIT source tag:
>
> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.4.1-incubating-rc0
>
> Staging site:
>
> https://dist.apache.org/repos/dist/dev/incubator/tez/tez-0.4.1-incubating-src-rc0/
>
> Nexus Staging URL:
> https://repository.apache.org/content/repositories/orgapachetez-1006/
>
> PGP release keys:
> http://pgp.mit.edu/pks/lookup?op=get&search=0x477E02D33DD51430
> KEYS file available at
> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
>
> List of issues fixed in the release:
> *https://issues.apache.org/jira/browse/TEZ/fixforversion/12327143/
> *
> Also available in CHANGES.txt within the release tarball.
>
> Vote will be open for at least 72 hours ( until the required number of IPMC
> votes are obtained).
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Thanks
>
> - Sid
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [VOTE] Accept Lens into the Apache Incubator (earlier called Grill)

[Vinod Kumar Vavilapalli]

Tx for starting this, Sharad!

+1, binding.

Thanks,
+Vinod

On Oct 6, 2014, at 4:51 AM, Sharad Agarwal  wrote:

> Following the discussion earlier in the thread
> https://www.mail-archive.com/general@incubator.apache.org/msg45208.html
> I would like to call a Vote for accepting Lens as a new incubator project.
> 
> The proposal is available at:
> https://wiki.apache.org/incubator/LensProposal
> 
> Vote is open till Oct 09, 2014 4 PM PST.
> 
> [ ] +1 accept Lens in the Incubator
> [ ] +/-0
> [ ] -1 because...
> 
> Only Votes from Incubator PMC members are binding, but all are welcome to
> express their thoughts.
> I am +1 (non-binding).
> 
> Thanks
> Sharad



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Graduate HCatalog from the incubator and become part of Hive

[Vinod Kumar Vavilapalli]

+1 non-binding.

Thanks,
+Vinod


On Wed, Feb 6, 2013 at 8:06 PM, Namit Jain  wrote:

> +1
>
>
> On 2/5/13 2:54 PM, "Alexander Alten-Lorenz"  wrote:
>
> >+1, non-binding
> >
> >- Alex
> >
> >On Feb 5, 2013, at 10:06 AM, Sushanth Sowmyan  wrote:
> >
> >> And my axe! Erm... I mean, my +1.
> >>
> >>
> >> On Mon, Feb 4, 2013 at 10:18 PM, Alan Gates 
> >>wrote:
> >>> FYI.
> >>>
> >>> Alan.
> >>>
> >>> Begin forwarded message:
> >>>
>  From: Alan Gates 
>  Date: February 4, 2013 10:18:09 PM PST
>  To: hcatalog-...@incubator.apache.org
>  Subject: [VOTE] Graduate HCatalog from the incubator and become part
> of Hive
> 
>  The Hive PMC has voted to accept HCatalog as a submodule of Hive.
> You can see the vote thread at
> 
> http://mail-archives.apache.org/mod_mbox/hive-dev/201301.mbox/%3cCACf6R
> rzktBYD0suZxn3Pfv8XkR=vgwszrzyb_2qvesuj2vh...@mail.gmail.com%3e .  We
> now need to vote to graduate from the incubator and become a submodule
> of Hive.  This entails the following:
> 
>  1) the establishment of an HCatalog submodule in the Apache Hive
> Project;
>  2) the adoption of the Apache HCatalog codebase into the Hive
> HCatalog submodule; and
>  3) adding all currently active HCatalog committers as submodule
> committers on the Hive HCatalog submodule.
> 
>  Definitions for all these can be found in the (now adopted) Hive
> bylaws at
> 
> https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hi
> ve+Bylaws+for+Submodule+Committer.
> 
>  This vote will stay open for at least 72 hours (thus 23:00 PST on
> 2/7/13).  PPMC members votes are binding in this vote, though input
> from all is welcome.
> 
>  If this vote passes the next step will be to submit the graduation
> motion to the Incubator PMC.
> 
>  Here's my +1.
> 
>  Alan.
> >>>
> >
> >--
> >Alexander Alten-Lorenz
> >http://mapredit.blogspot.com
> >German Hadoop LinkedIn Group: http://goo.gl/N8pCF
> >
>
>


-- 
+Vinod
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator

[Vinod Kumar Vavilapalli]

+1 (non-binding)

Thanks,
+Vinod

On Feb 15, 2013, at 11:22 AM, Devaraj Das wrote:

> Hi Folks,
> 
> Thanks for participating in the discussion. I'd like to call a VOTE
> for acceptance of Apache Knox Hadoop Gateway Project into the
> Incubator. The vote will close on Feb 22 at 6:00 p.m.
> 
> [ ]  +1 Accept Apache Knox Hadoop Gateway Project into the Incubator
> [ ]  +0 Don't care.
> [ ]  -1 Don't accept Apache Knox Hadoop Gateway Project into the
> Incubator because...
> 
> Full proposal is pasted at the bottom of this email, and the
> corresponding wiki is http://wiki.apache.org/incubator/knox. Only
> VOTEs from Incubator PMC members are binding.
> 
> Here's my +1 (binding).
> 
> Thanks,
> Devaraj.
> 
> -
> 
> Knox Gateway Proposal
> 
> Abstract
> 
> Knox Gateway is a system that provides a single point of secure access
> for Apache Hadoop clusters.
> 
> Proposal
> 
> The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
> single point of authentication and access for Apache Hadoop services
> in a cluster. The goal is to simplify Hadoop security for both users
> (i.e. who access the cluster data and execute jobs) and operators
> (i.e. who control access and manage the cluster). The Gateway runs as
> a server (or cluster of servers) that serve one or more Hadoop
> clusters.
> 
> Provide perimeter security to make Hadoop security setup easier
> Support authentication and token verification security scenarios
> Deliver users a single cluster end-point that aggregates capabilities
> for data and jobs
> Enable integration with enterprise and cloud identity management environments
> 
> Background
> 
> An Apache Hadoop cluster is presented to consumers as a loose
> collection of independent services. This makes it difficult for users
> to interact with Hadoop since each service maintains it’s own method
> of access and security. As well, for operators, configuration and
> administration of a secure Hadoop cluster is a complex and many Hadoop
> clusters are insecure as a result.
> 
> The goal of the project is to provide coverage for all existing Hadoop
> ecosystem projects. In addition, the project will be extensible to
> allow for new and/or proprietary Hadoop components without requiring
> changes to the gateway source code. The gateway is expected to run in
> a DMZ environment where it will provide controlled access to these
> Hadoop services. In this way Hadoop clusters can be protected by a
> firewall and only limited access provided through the firewall for the
> gateway. The authentication components of the gateway will be modular
> and extensible such that it can be integrated with existing security
> infrastructure.
> 
> Rationale
> 
> Organizations that are struggling with Hadoop cluster security result
> in a) running Hadoop without security or b) slowing adoption of
> Hadoop. The Gateway aims to provide perimeter security that integrates
> more easily into existing organizations’ security infrastructure.
> Doing so will simplify security for these organizations and benefit
> all Hadoop stakeholders (i.e. users and operators). Additionally,
> making a dedicated perimeter security project part of the Apache
> Hadoop ecosystem will prevent fragmentation in this area and further
> increase the value of Hadoop as a data platform.
> 
> Current Status
> 
> Prototype available, developed by the list of initial committers.
> 
> Meritocracy
> 
> We desire to build a diverse developer community around Gateway
> following the Apache Way. We want to make the project open source and
> will encourage contributors from multiple organizations following the
> Apache meritocracy model.
> 
> Community
> 
> We hope to extend the user and developer base in the future and build
> a solid open source community around Gateway. Apache Hadoop has a
> large ecosystem of open source projects, each with a strong community
> of contributors. All project communities in this ecosystem have an
> opportunity to participate in the advancement of the Gateway project
> because ultimately, Gateway will enable the security capabilities of
> their project to be more enterprise friendly.
> 
> Core Developers
> 
> Gateway is currently being developed by several engineers from
> Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower
> and Sumit Mohanty. All the engineers have deep expertise in
> middleware, security & identity systems and are quite familiar with
> the Hadoop ecosystem.
> 
> Alignment
> 
> The ASF is a natural host for Gateway given that it is already the
> home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data
> software projects. Gateway is designed to solve the security
> challenges familiar to the Hadoop ecosystem family of projects.
> 
> Known Risks
> 
> Orphaned products & Reliance on Salaried Developers
> 
> The core developers plan to work full time on the project. We believe
> that this project will be of general interest to many Hadoop users and
> will attract a

Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator

[Vinod Kumar Vavilapalli]

This thread is dead because of needed edits to the proposal, please vote on the 
other voting thread.

Thanks,
+Vinod

On Feb 19, 2013, at 11:43 AM, Hitesh Shah wrote:

> +1 ( non-binding )
> 
> -- Hitesh
> 
> On Feb 14, 2013, at 5:26 PM, Devaraj Das wrote:
> 
>> Hi Folks,
>> 
>> Thanks for participating in the discussion. I'd like to call a VOTE
>> for acceptance of Apache Knox Hadoop Gateway Project into the
>> Incubator. The vote will close on Feb 21 at 6:00 p.m.
>> 
>> [ ]  +1 Accept Apache Open Climate Workbench into the Incubator
>> [ ]  +0 Don't care.
>> [ ]  -1 Don't accept Apache Open Climate Workbench into the Incubator 
>> because...
>> 
>> Full proposal is pasted at the bottom of this email, and the
>> corresponding wiki is http://wiki.apache.org/incubator/knox. Only
>> VOTEs from Incubator PMC members are binding.
>> 
>> Here's my +1 (binding).
>> 
>> Thanks,
>> Devaraj.
>> 
>> p.s. In the last day, Tom White has been added as a mentor, and
>> Venkatesh Seetharam has been added in the list of initial committers.
>> 
>> 
>> Knox Gateway Proposal
>> 
>> Abstract
>> 
>> Knox Gateway is a system that provides a single point of secure access
>> for Apache Hadoop clusters.
>> 
>> Proposal
>> 
>> The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
>> single point of authentication and access for Apache Hadoop services
>> in a cluster. The goal is to simplify Hadoop security for both users
>> (i.e. who access the cluster data and execute jobs) and operators
>> (i.e. who control access and manage the cluster). The Gateway runs as
>> a server (or cluster of servers) that serve one or more Hadoop
>> clusters.
>> 
>> Provide perimeter security to make Hadoop security setup easier
>> Support authentication and token verification security scenarios
>> Deliver users a single cluster end-point that aggregates capabilities
>> for data and jobs
>> Enable integration with enterprise and cloud identity management environments
>> 
>> Background
>> 
>> An Apache Hadoop cluster is presented to consumers as a loose
>> collection of independent services. This makes it difficult for users
>> to interact with Hadoop since each service maintains it’s own method
>> of access and security. As well, for operators, configuration and
>> administration of a secure Hadoop cluster is a complex and many Hadoop
>> clusters are insecure as a result.
>> 
>> The goal of the project is to provide coverage for all existing Hadoop
>> ecosystem projects. In addition, the project will be extensible to
>> allow for new and/or proprietary Hadoop components without requiring
>> changes to the gateway source code. The gateway is expected to run in
>> a DMZ environment where it will provide controlled access to these
>> Hadoop services. In this way Hadoop clusters can be protected by a
>> firewall and only limited access provided through the firewall for the
>> gateway. The authentication components of the gateway will be modular
>> and extensible such that it can be integrated with existing security
>> infrastructure.
>> 
>> Rationale
>> 
>> Organizations that are struggling with Hadoop cluster security result
>> in a) running Hadoop without security or b) slowing adoption of
>> Hadoop. The Gateway aims to provide perimeter security that integrates
>> more easily into existing organizations’ security infrastructure.
>> Doing so will simplify security for these organizations and benefit
>> all Hadoop stakeholders (i.e. users and operators). Additionally,
>> making a dedicated perimeter security project part of the Apache
>> Hadoop ecosystem will prevent fragmentation in this area and further
>> increase the value of Hadoop as a data platform.
>> 
>> Current Status
>> 
>> Prototype available, developed by the list of initial committers.
>> 
>> Meritocracy
>> 
>> We desire to build a diverse developer community around Gateway
>> following the Apache Way. We want to make the project open source and
>> will encourage contributors from multiple organizations following the
>> Apache meritocracy model.
>> 
>> Community
>> 
>> We hope to extend the user and developer base in the future and build
>> a solid open source community around Gateway. Apache Hadoop has a
>> large ecosystem of open source projects, each with a strong community
>> of contributors. All project communities in this ecosystem have an
>> opportunity to participate in the advancement of the Gateway project
>> because ultimately, Gateway will enable the security capabilities of
>> their project to be more enterprise friendly.
>> 
>> Core Developers
>> 
>> Gateway is currently being developed by several engineers from
>> Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower
>> and Sumit Mohanty. All the engineers have deep expertise in
>> middleware, security & identity systems and are quite familiar with
>> the Hadoop ecosystem.
>> 
>> Alignment
>> 
>> The ASF is a natural host for Gateway given that it is already the
>> home of Hadoop, Hive, Pig

Re: [VOTE] Accept Tez into Incubator

[Vinod Kumar Vavilapalli]

+1 (non-binding)

Thanks,
+Vinod

On Feb 19, 2013, at 8:26 PM, Arun C Murthy wrote:

> Hi Folks,
> 
> Thanks for participating in the discussion. I'd like to call a VOTE for 
> acceptance of Apache Tez into the Incubator. I'll let the vote run till into 
> this weekend (Sun 2/24 6pm PST).
> 
> [ ]  +1 Accept Apache Tez into the Incubator
> [ ]  +0 Don't care.
> [ ]  -1 Don't accept Apache Tez into the Incubator because...
> 
> Full proposal is pasted at the bottom of this email, and the corresponding 
> wiki is http://wiki.apache.org/incubator/TezProposal. 
> 
> Only VOTEs from Incubator PMC members are binding, but all are welcome to 
> express their thoughts.
> 
> Here's my +1 (binding).
> 
> thanks,
> Arun
> 
> PS: From the initial discussion, the only changes are that I've added one new 
> mentor and 2 new committers. All the new additions come from the non-major 
> employer while we continue to strive to further diversify during the 
> incubation. Thanks.
> 
> 
> 
> = Tez =
> 
> == Abstract ==
> Tez is an effort to develop a generic application framework which can be used
> to process arbitrarily complex data-processing tasks and also a re-usable set
> of data-processing primitives which can be used by other projects.
> 
> == Proposal ==
> Tez is a proposal to develop a generic application which can be used to
> process complex data-processing task DAGs and runs natively on Apache Hadoop 
> YARN. YARN is a generic resource-management system on which currently 
> applications like MapReduce already exist. MapReduce is a specific, and
> constrained, DAG - which is not optimal for several frameworks like Apache 
> Hive
> and Apache Pig. Furthermore, we propose to develop a re-usable set of
> libraries of data-processing primitives such as sorting, merging,
> data-shuffling, intermediate data management etc. which are necessary for Tez 
> which we envision can be used directly by other projects. 
> 
> == Background ==
> Apache Hadoop MapReduce has emerged as the assembly-language on which other
> frameworks like Apache Pig and Apache Hive have been built. However, it has
> been well accepted that MapReduce produces very constrained task DAGs for each
> job which results in Apache Pig and Apache Hive requiring multiple MapReduce
> jobs for several queries. By providing a more expressive DAG of tasks for a
> job, Tez attempts to provide significantly enhanced data-processing
> capabilities for projects like Apache Pig, Apache Hive, Cascading etc.
> 
> == Rationale ==
> There is an important gap that Tez fulfills in the Apache Hadoop ecosystem of
> allowing for more expressive task DAGs for data-processing applications such
> as Apache Pig, Apache Hive, Cascading etc.
> 
> With emergence of Apache Hadoop YARN, there is a strong need for a
> common DAG application which can then be shared by Apache Pig, Apache Hive,
> Cascading etc.
> 
> == Initial Goals ==
> The initial goals for this project are to specify the detailed requirements
> and architecture, and then develop the initial implementation including the
> DAG ApplicationMaster to run natively inside Apache Hadoop YARN. 
> 
> == Current Status ==
> Significant work has been completed to identify the initial requirements and
> define the overall system architecture. There is a patch available in the
> internal Hortonworks git repository which can act as the initial seed. 
> 
> === Meritocracy ===
> We plan to invest in supporting a meritocracy. We will discuss the 
> requirements 
> in an open forum. Several companies have already expressed interest in this 
> project, and we intend to invite additional developers to participate. 
> We will encourage and monitor community participation so that privileges can 
> be 
> extended to those that contribute. 
> 
> === Community ===
> The need for a generic DAG application for data processing in the open source 
> is 
> tremendous, so there is a potential for a very large community. We believe
> that Tez's extensible architecture will further encourage community 
> participation. 
> Also, related Apache projects (eg, Pig, Hive) have very large and active 
> communities, and we expect that over time Tez will also attract a large 
> community.
> 
> === Core Developers ===
> The developers on the initial committers list include people very experienced
> in the Apache Hadoop ecosystem:
> 
> * Alan Gates 
> * Arun C Murthy 
> * Ashutosh Chauhan 
> * Bikas Saha 
> * Chris Douglas 
> * Daryn Sharp 
> * Devaraj Das 
> * Gopal Vijayaraghavan 
> * Gunther Hagleitner 
> * Hitesh Shah 
> * Jason Lowe 
> * Jean Xu 
> * Jitendra Pandey 
> * Julien Le

Re: [PROPOSAL] Ivory - Hadoop data management and processing platform

[Vinod Kumar Vavilapalli]

+1, this will be a great addition to the Hadoop eco-system!

The proposal looks fine overall. I quickly searched around for the name ivory, 
it looks to be a safe one, but someone needs to do due diligence?

And I think you can chose to have git as the version control if you feel like 
it.

Thanks,
+Vinod Kumar Vavilapalli

On Mar 13, 2013, at 10:00 AM, Srikanth Sundarrajan wrote:

> = Ivory Proposal =
> 
> == Abstract ==
> Ivory is a data processing and management solution for Hadoop designed for
> data motion, coordination of data pipelines, lifecycle management, and
> data discovery. Ivory enables end consumers to quickly onboard their data
> and its associated processing and management tasks on Hadoop clusters.
> 
> == Proposal ==
> Ivory will enable easy data management via declarative mechanism for
> Hadoop. Users of Ivory platform simply define infrastructure endpoints,
> data sets and processing rules declaratively. These configurations
> are expressed in such a way that the dependencies between
> these entities are explicitly described. This information about
> inter-dependencies between various entities allows Ivory to orchestrate and
> manage various data management functions.
> 
> The key use cases that Ivory addresses are:
> * Data Motion
> * Process orchestration and scheduling
> * Policy-based Lifecycle Management
> * Data Discovery
> * Operability/Usability
> 
> With these features it is possible for users to onboard their data sets
> with
> a comprehensive and holistic understanding of how, when and where their
> data
> is managed across its lifecycle. Complex functions such as retrying
> failures,
> identifying possible SLA breaches or automated handling of input data
> changes
> are now simple directives. All the administrative functions and user level
> functions are available via RESTful APIs. CLI is simply a wrapper over the
> RESTful APIs.
> 
> == Background ==
> Hadoop and its ecosystem of products have made storing and processing
> massive
> amounts of data commonplace. This has enabled numerous organizations to
> gain
> valuable insights that they never could have achieved in the past. While it
> is easy to leverage Hadoop for crunching large volumes of data, organizing
> data, managing life cycle of data and processing data is fairly involved.
> This is solved adequately well in a classic data platform involving data
> warehouses and standard ETL (extract-transform-load) tools, but remains
> largely
> unsolved today. In addition to data processing complexities, Hadoop
> presents
> new sets of challenges and opportunities relating to management of data.
> 
> Data Management on Hadoop encompasses data motion, process orchestration,
> lifecycle management, data discovery, etc. among other concerns that are
> beyond
> ETL. Ivory is a new data processing and management platform for Hadoop that
> solves this problem and creates additional opportunities by building on
> existing
> components within the Hadoop ecosystem (ex. Apache Oozie, Apache Hadoop
> DistCp
> etc.) without reinventing the wheel. Ivory has been in production at
> InMobi,
> going on its second year and has been managing hundreds of feeds and
> processes.
> 
> Ivory is being developed by engineers employed with InMobi, Hortonworks and
> Yahoo!. This platform addition will increase the adoption of Apache Hadoop
> by
> driving data management tractable for end users. We are therefore proposing
> to
> make Ivory an Apache open source project.
> 
> == Rationale ==
> The Ivory project aims to improve the usability of Apache Hadoop. As a
> result
> Apache Hadoop will grow its community of users by increasing the places
> Hadoop
> can be utilized and the use cases it will solve. By developing Ivory in
> Apache
> we hope to gather a diverse community of contributors, helping to ensure
> that
> Ivory is deployable for a broad range of scenarios. Members of the Hadoop
> development community will be able to influence Ivory’s roadmap, and
> contribute
> to it. We believe having Ivory as part of the Apache Hadoop ecosystem will
> be
> a great benefit to all of Hadoop's users.
> 
> == Current Status ==
> Ivory is widely deployed in production within InMobi and moving on to its
> second year. A version with a valuable set of features is developed by the
> list of initial committers and is hosted on github.
> 
> === Meritocracy ===
> Our intent with this incubator proposal is to start building a diverse
> developer
> community around Ivory following the Apache meritocracy model. We have
> wanted to
> make the project open source and encourage contributors from multiple
> organizations from the start. We plan to provide plenty of sup

Re: [VOTE] Accept Falcon into the Apache Incubator (was originally named Ivory)

[Vinod Kumar Vavilapalli]

+1 (non-binding)

Thanks,
+Vinod Kumar Vavilapalli

On Mar 20, 2013, at 9:54 PM, Srikanth Sundarrajan wrote:

> Hi,
> 
> Thanks for participating in the proposal discussion on Falcon
> (formerly Ivory). I'd like to call a VOTE for acceptance of Apache
> Falcon into the Incubator. I'll let the vote run till (Tue 3/26 6pm IST).
> 
> [ ]  +1 Accept Apache Falcon into the Incubator
> [ ]  +0 Don't care.
> [ ]  -1 Don't accept Apache Falcon into the Incubator because...
> 
> Full proposal is pasted at the bottom of this email, and the
> corresponding wiki is http://wiki.apache.org/incubator/FalconProposal.
> 
> 
> Only VOTEs from Incubator PMC members are binding, but all are welcome
> to express their thoughts.
> 
> Thanks,
> Srikanth Sundarrajan
> = Falcon Proposal =
> 
> == Abstract ==
> Falcon is a data processing and management solution for Hadoop
> designed for data motion, coordination of data pipelines, lifecycle
> management, and data discovery. Falcon enables end consumers to
> quickly onboard their data and its associated processing and
> management tasks on Hadoop clusters.
> 
> == Proposal ==
> Falcon will enable easy data management via declarative mechanism for
> Hadoop. Users of Falcon platform simply define infrastructure
> endpoints, data sets and processing rules declaratively. These
> declarative configurations are expressed in such a way that the
> dependencies between these configured entities are explicitly
> described. This information about inter-dependencies between various
> entities allows Falcon to orchestrate and manage various data
> management functions.
> 
> The key use cases that Falcon addresses are:
> * Data Motion
> * Process orchestration and scheduling
> * Policy-based Lifecycle Management
> * Data Discovery
> * Operability/Usability
> 
> With these features it is possible for users to onboard their data
> sets with a comprehensive and holistic understanding of how, when and
> where their data is managed across its lifecycle. Complex functions
> such as retrying failures, identifying possible SLA breaches or
> automated handling of input data changes are now simple directives.
> All the administrative functions and user level functions are
> available via RESTful APIs. CLI is simply a wrapper over the RESTful
> APIs.
> 
> == Background ==
> Hadoop and its ecosystem of products have made storing and processing
> massive amounts of data commonplace. This has enabled numerous
> organizations to gain valuable insights that they never could have
> achieved in the past. While it is easy to leverage Hadoop for
> crunching large volumes of data, organizing data, managing life cycle
> of data and processing data is fairly involved. This is solved
> adequately well in a classic data platform involving data warehouses
> and standard ETL (extract-transform-load) tools, but remains largely
> unsolved today. In addition to data processing complexities, Hadoop
> presents new sets of challenges and opportunities relating to
> management of data.
> 
> Data Management on Hadoop encompasses data motion, process
> orchestration, lifecycle management, data discovery, etc. among other
> concerns that are beyond ETL. Falcon is a new data processing and
> management platform for Hadoop that solves this problem and creates
> additional opportunities by building on existing components within the
> Hadoop ecosystem (ex. Apache Oozie, Apache Hadoop DistCp etc.) without
> reinventing the wheel. Falcon has been in production at InMobi, going
> on its second year and has been managing hundreds of feeds and
> processes.
> 
> Falcon is being developed by engineers employed with InMobi and
> Hortonworks. This platform addition will increase the adoption of
> Apache Hadoop by driving data management tractable for end users. We
> are therefore proposing to make Falcon an Apache open source project.
> 
> == Rationale ==
> The Falcon project aims to improve the usability of Apache Hadoop. As
> a result Apache Hadoop will grow its community of users by increasing
> the places Hadoop can be utilized and the use cases it will solve. By
> developing Falcon in Apache we hope to gather a diverse community of
> contributors, helping to ensure that Falcon is deployable for a broad
> range of scenarios. Members of the Hadoop development community will
> be able to influence Falcon’s roadmap, and contribute to it. We
> believe having Falcon as part of the Apache Hadoop ecosystem will be a
> great benefit to all of Hadoop's users.
> 
> == Current Status ==
> Falcon is widely deployed in production within InMobi and moving on to
> its second year. A version with a valuable set of features is
> developed

Re: [PROPOSAL] S4 for the Apache Incubator

[Vinod Kumar Vavilapalli]

Great addition to Apache, +1.

Some comments on the proposal:
 - In the "Initial Goals" section, you referred to "Add a cluster management
system". Not sure of what it entirely means, but if it is what I think it
is, the new resource-management layer in Hadoop (YARN/ JIRA issue
MAPREDUCE-279) can be leveraged for this. YARN is going to be available in
Hadoop 0.23 release. Willing to help in this regard in any way possible if
you think it makes sense for S4, can have a separate discussion too.
 - You may want to capture the discussion about Hdaoop/Flume/Kafka in the
"Relationships with Other Apache Projects" section.
 - Seen elsewhere that proposals list down the list of companies of the
initial set of committers (section "Homogeneous Developers").

Thanks,
+Vinod

On Thu, Sep 15, 2011 at 1:49 AM, Leo Neumeyer  wrote:

> Dear all,
>
> I would like to propose S4 to be an Apache Incubator project.  S4 is a
> distributed streaming platform written in Java.
>
> Here is a link to the proposal in the Incubator wiki:
> http://wiki.apache.org/incubator/S4Proposal
>
> Thanks,
> Leo Neumeyer
>
> http://s4.io
> http://twitter.com/leoneu
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] S4 for the Apache Incubator

[Vinod Kumar Vavilapalli]

On Mon, Sep 19, 2011 at 10:43 PM, Flavio Junqueira  wrote:

> To give you an idea of what we have in mind, here are a few points:
>
> - Monitor Nodes and PEs.
> - Ability to  query specific PE instance variables.
> - Add remove nodes.
> - Monitor logs.
> - Monitor CPU/Memory usage per node.
> - Load/unload apps.
>


It does look like some of the resource management can be offloaded to YARN.



> In general, it sounds right to assess if it is viable to use YARN for S4
> cluster management and we would appreciate your help. If it is ok with you,
> I'd rather not include it in the proposal, though, since it is an issue we
> could consider independently of the project going into incubator. Let me
> know if you agree.
>


Definitely.

Thanks,
+Vinod

Re: [VOTE] S4 to join the Incubator

[Vinod Kumar Vavilapalli]

+1 (non-binding)

+Vinod

On Wed, Sep 21, 2011 at 2:26 AM, Patrick Hunt  wrote:

> It's been a nearly a week since the S4 proposal was submitted for
> discussion.  A few questions were asked, and the proposal was clarified
> in response.  Sufficient mentors have volunteered.  I thus feel we are
> now ready for a vote.
>
> The latest proposal can be found at the end of this email and at:
>
>  http://wiki.apache.org/incubator/S4Proposal
>
> The discussion regarding the proposal can be found at:
>
>  http://s.apache.org/RMU
>
> Please cast your votes:
>
> [  ] +1 Accept S4 for incubation
> [  ] +0 Indifferent to S4 incubation
> [  ] -1 Reject S4 for incubation
>
> This vote will close 72 hours from now.
>
> Thanks,
>
> Patrick
>
> --
> = S4 Proposal =
>
> == Abstract ==
>
> S4 (Simple Scalable Streaming System) is a general-purpose,
> distributed, scalable, partially fault-tolerant, pluggable platform
> that allows programmers to easily develop applications for processing
> continuous, unbounded streams of data.
>
> == Proposal ==
>
> S4 is a software platform written in Java. Clients that send and
> receive events can be written in any programming language. S4 also
> includes a collection of modules called Processing Elements (or PEs
> for short) that implement basic functionality and can be used by
> application developers. In S4, keyed data events are routed with
> affinity to Processing Elements (PEs), which consume the events and do
> one or both of the following: (1) ''emit'' one or more events which
> may be consumed by other PEs, (2) ''publish'' results. The
> architecture resembles the Actors model, providing semantics of
> encapsulation and location transparency, thus allowing applications to
> be massively concurrent while exposing a simple programming  interface
> to application developers.
>
> To drive adoption and increase the number of contributors to the
> project, we may need to prioritize the focus based on feedback from
> the community. We believe that one of the top priorities and driving
> design principle for the S4 project is to provide a simple API that
> hides most of the complexity associated with distributed systems and
> concurrency. The project grew out of the need to provide a flexible
> platform for application developers and scientists that can be used
> for quick experimentation and production.
>
> S4 differs from existing Apache projects in a number of fundamental
> ways. Flume is an Incubator project that focuses on log processing,
> performing lightweight processing in a distributed fashion and
> accumulating log data in a centralized repository for batch
> processing. S4 instead performs all stream processing in a distributed
> fashion and enables applications to form arbitrary graphs to process
> streams of events. We see Flume as a complementary project. We also
> expect S4 to complement Hadoop processing and in some cases to
> supersede it. Kafka is another Incubator project that focuses on
> processing large amounts of stream data. The design of Kafka, however,
> follows the pub-sub paradigm, which focuses on delivering messages
> containing arbitrary data from source processes (publishers) to
> consumer processes (subscribers). Compared to S4, Kafka is an
> intermediate step between data generation and processing, while S4 is
> itself a platform for processing streams of events.
>
> S4 overall addresses a need of existing applications to process
> streams of events beyond moving data to a centralized repository for
> batch processing. It complements the features of existing Apache
> projects, such as Hadoop, Flume, and Kafka, by providing a flexible
> platform for distributed event processing.
>
> == Background ==
>
> S4 was initially developed at Yahoo! Labs starting in 2008 to process
> user feedback in the context of search advertising. The project was
> licensed under the Apache License version 2.0 in October 2010. The
> project documentation is currently available at http://s4.io .
>
> == Rationale ==
>
> Stream computing has been growing steadily over the last 20 years.
> However, recently there has been an explosion in real-time data
> sources including the Web, sensor networks, financial securities
> analysis and trading, traffic monitoring, natural language processing
> of news and social data, and much more.
>
> As Hadoop evolved as a standard open source solution for batch
> processing of massive data sets, there is no equivalent community
> supported open source platform for processing data streams in
> real-time. While various research projects have evolved into
> proprietary commercial products, S4 has the potential to fill the gap.
> Many projects that require a scalable stream processing architecture
> currently use Hadoop by segmenting the input stream into data batches.
> This solution is not efficient, results in high latency, and
> introduces unnecessary complexity.
>
> The S4 design is primarily driven by large scale applications f

Re: [VOTE] accept DirectMemory as new Apache Incubator podling

[Vinod Kumar Vavilapalli]

Very interesting project.

+1 (non-binding).

Thanks,
+Vinod


On Sun, Oct 2, 2011 at 1:06 PM, Simone Tripodi wrote:

> Hi all guys,
>
> I'm now calling a formal VOTE on the DirectMemory proposal located here:
>
> http://wiki.apache.org/incubator/DirectMemoryProposal
>
> Proposal text copied at the bottom of this email.
>
> VOTE close on Tuesday, October 4, early 7:30 AM CET.
>
> Please VOTE:
>
> [ ] +1 Accept DirectMemory into the Apache Incubator
> [ ] +0 Don't care
> [ ] -1  Don't Accept DirectMemory into the Apache Incubator because...
>
> Thanks in advance for participating!
>
> All the best, have a nice day,
> Simo
>
> P.S. Here's my +1
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> = DirectMemory =
>
> == Abstract ==
> The following proposal is about Apache !DirectMemory, a Java
> !OpenSource multi-layered cache implementation featuring off-heap
> memory storage (a-la Terracotta !BigMemory) to enable caching of Java
> objects without degrading JVM performance
>
> == Proposal ==
> !DirectMemory's main purpose is to to act as a second level cache
> (after a heap based one) able to store large amounts of data without
> filling up the Java heap and thus avoiding long garbage collection
> cycles. Although serialization has a runtime cost store/retrieve
> operations are in the sub-millisecond range being pretty acceptable in
> every usage scenario even as a first level cache and, most of all,
> outperforms heap storage when the count of the entries goes over a
> certain amount. !DirectMemory implements cache eviction based on a
> simple LFU (Least Frequently Used) algorythm and also on item
> expiration. Included in the box is a small set of utility classes to
> easily handle off-heap memory buffers.
>
> == Background ==
> !DirectMemory is a project was born in the 2010 thanks to Raffaele P.
> Guidi initial effort under
> [[https://github.com/raffaeleguidi/!DirectMemory/|GitHub]] and already
> licensed under the Apache License 2.0.
>
> == Rationale ==
> The rationale behind !DirectMemory is bringing off-heap caching to the
> open source world, empowering FOSS developers and products with a tool
> that enables breaking the heap barrier and override the JVM garbage
> collection mechanism collection - which could be useful in scenarios
> where RAM needs are over the usual limits (more than 8, 12, 24gb) and
> to ease usage of off-heap memory in general
>
> = Current Status =
>
> == Meritocracy ==
> As a majority of the initial project members are existing ASF
> committers, we recognize the desirability of running the project as a
> meritocracy.  We are eager to engage other members of the community
> and operate to the standard of meritocracy that Apache emphasizes; we
> believe this is the most effective method of growing our community and
> enabling widespread adoption.
>
> == Core Developers ==
> In alphabetical order:
>
>  * Christian Grobmeier 
>  * Maurizio Cucchiara 
>  * Olivier Lamy 
>  * Raffaele P. Guidi 
>  * Simone Gianni 
>  * Simone Tripodi 
>  * Tommaso Teofili 
>
> == Alignment ==
> The purpose of the project is to develop and maintain !DirectMemory
> implementation that can be used by other Apache projects.
>
> = Known Risks =
> == Orphaned Products ==
> !DirectMemory does not have any reported production usage, yet, but is
> getting traction with developers and being evaluated by potential
> users and thus the risks of it being orphaned are minimal
>
> == Inexperience with Open Source ==
> All of the committers have experience working in one or more open
> source projects inside and outside ASF.
>
> == Homogeneous Developers ==
> The list of initial committers are geographically distributed across
> the Europe with no one company being associated with a majority of the
> developers.  Many of these initial developers are experienced Apache
> committers already and all are experienced with working in distributed
> development communities.
>
> == Reliance on Salaried Developers ==
> To the best of our knowledge, none of the initial committers are being
> paid to develop code for this project.
>
> == Relationships with Other Apache Products ==
> !DirectMemory fits naturally in the ASF because it could be
> successfully employed together with a large number of ASF products
> ranging from JCS - as a new cache region between the heap and indexed
> file ones, to ORM systems like Cayenne (i.e. replacing current OSCache
> based implementation), Apache JDO and JPA implementations and also
> java based databases (i.e. Derby) and all systems managing large
> amounts of data from Hadoop to Cassandra
>
> == A Excessive Fascination with the Apache Brand ==
> While the Apache Software Foundation would be a good home for the
> !DirectMemory project it already has some traction and it could live
> on its own - however we see reciprocal benefits for both the ASF and
> the project in adopting the brand to better reach the community
>
> = Documentation =
>  1. [[https://github.com/raff

Re: [DISCUSS] Crunch to join the Apache Incubator

[Vinod Kumar Vavilapalli]

+1, great addition. Looking forward to see this at Apache!

I'd like to add myself to the list of initial committers if that is fine with 
you. (Didn't find any section for interested developers in the proposal, so 
asking here)

My Background: Long time Hadoop MapReduce committer. Lead dev on Hadoop 
next-gen MapReduce aka YARN. Familiar with / know a bit or two about FlumeJava.

Thanks,
+Vinod


On May 15, 2012, at 5:23 PM, Josh Wills wrote:

> Hi all,
> 
> I would like to propose Crunch, a library for writing MapReduce
> pipelines in Java and Scala, as an Apache Incubator project. The
> proposal is here:
> 
> http://wiki.apache.org/incubator/CrunchProposal
> 
> We would gladly welcome additional volunteers to act as mentors on the
> project, so if this sounds like your cup of tea, please feel free to
> sign up or let us know.
> 
> Thanks!
> Josh
> 
> -- 
> Director of Data Science
> Cloudera
> Twitter: @josh_wills
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Crunch into the Apache Incubator

[Vinod Kumar Vavilapalli]

izations is a strong indication that Crunch will be
> widely adopted.
> 
> == Reliance on Salaried Developers ==
> 
> It is expected that Crunch will be developed on salaried and volunteer
> time, although all of the initial developers will work on it mainly on
> salaried time.
> 
> == Relationships with Other Apache Products ==
> 
> Crunch depends upon other Apache Projects: Apache Hadoop, Apache
> HBase, Apache Log4J, Apache Thrift, Apache Avro, and multiple Apache
> Commons components. Its build depends upon Apache Maven.
> 
> Crunch's functionality has some indirect or direct overlap with the
> functionality of Apache Pig and Apache Hive but has several
> significant differences in terms of their user community and the types
> of data they are designed to work with.  Both Hive and Pig are
> high-level languages that are designed to allow non-programmers to
> quickly create and run !MapReduce jobs. Crunch is a Java library whose
> primary community is Java developers who are creating scalable data
> pipelines and !MapReduce-based applications. Additionally, Hive and
> Pig both employ a relational, tuple-oriented data model on top of
> HDFS, which introduces overhead and limits expressive power for
> developers who are working with serialized objects and non-relational
> data types. Crunch uses a lower-level data model that gives developers
> the freedom to work with data in a format that is optimized for the
> problem they are trying to solve.
> 
> == An Excessive Fascination with the Apache Brand ==
> 
> We would like Crunch to become an Apache project to further foster a
> healthy community of contributors and consumers around the project.
> Since Crunch directly interacts with many Apache Hadoop-related
> projects and solves an important problem of many Hadoop users,
> residing in the Apache Software Foundation will increase interaction
> with the larger community.
> 
> = Documentation =
> 
> * Crunch wiki at GitHub: https://github.com/cloudera/crunch/wiki
> * Crunch jira at Cloudera: https://issues.cloudera.org/browse/crunch
> * Crunch javadoc at GitHub: http://cloudera.github.com/crunch/apidocs/
> 
> = Initial Source =
> 
> * https://github.com/cloudera/crunch/tree/
> 
> == Source and Intellectual Property Submission Plan ==
> 
> * The initial source is already licensed under the Apache License,
> Version 2.0. https://github.com/cloudera/crunch/blob/master/LICENSE.txt
> 
> == External Dependencies ==
> 
> The required external dependencies are all Apache License or
> compatible licenses. Following components with non-Apache licenses are
> enumerated:
> 
> * com.google.protobuf : New BSD
> * org.hamcrest: New BSD
> * org.slf4j: MIT-like License
> 
> Non-Apache build tools that are used by Crunch are as follows:
> 
> * Cobertura: GNU GPLv2
> 
> Note that Cobertura is optional and is only used for calculating unit
> test coverage.
> 
> == Cryptography ==
> 
> Crunch uses standard APIs and tools for SSH and SSL communication
> where necessary.
> 
> = Required  Resources =
> 
> == Mailing lists ==
> 
> * crunch-private (with moderated subscriptions)
> * crunch-dev
> * crunch-commits
> * crunch-user
> 
> == Github Repositories ==
> 
> http://github.com/apache/crunch
> git://git.apache.org/crunch.git
> 
> == Issue Tracking ==
> 
> JIRA Crunch (CRUNCH)
> 
> == Other Resources ==
> 
> The existing code already has unit and integration tests so we would
> like a Jenkins instance to run them whenever a new patch is submitted.
> This can be added after project creation.
> 
> = Initial Committers =
> 
> * Brock Noland (brock at cloudera dot com)
> * Josh Wills (jwills at cloudera dot com)
> * Gabriel Reid (gabriel dot reid at gmail dot com)
> * Tom White (tom at cloudera dot com)
> * Christian Tzolov (christian dot tzolov at gmail dot com)
> * Robert Chu (robert at wibidata dot com)
> * Vinod Kumar Vavilapalli (vinodkv at hortonworks dot com)
> 
> = Affiliations =
> 
> * Brock Noland, Cloudera
> * Josh Wills, Cloudera
> * Gabriel Reid, !TomTom
> * Tom White, Cloudera
> * Christian Tzolov, !TomTom
> * Robert Chu, !WibiData
> * Vinod Kumar Vavilapalli, Hortonworks
> 
> = Sponsors =
> 
> == Champion ==
> 
> * Patrick Hunt
> 
> == Nominated Mentors ==
> 
> * Tom White
> * Patrick Hunt
> * Arun Murthy
> 
> == Sponsoring Entity ==
> 
> * Apache Incubator PMC
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Metron into Apache Incubator

[Vinod Kumar Vavilapalli]

o being a successful
> Apache project.
> 
> === Community ===
> The OpenSOC project is not responding to pull requests or making releases.
> The easiest solution would be to create a variety of forks of the project
> on github, but that would further fracture the community and prevent it
> from reaching critical mass. Our prefered solution is to build a single
> large diverse and open community at Apache.
> 
> === Core Developers ===
> The core developers of Metron are James Sirota, Charles Porter, and Mark
> Bittmann. None of them have experience running an open source project, but
> they are eager to learn.
> 
> === Alignment ===
> The ASF is a natural host for Metron given that it is already the home of
> Hadoop, HBase, Hive, Storm, Kafka, Spark and other emerging big data
> projects. Metron leverages many of Apache open-source products. We are very
> interested in a place to develop our community and integrations with the
> other Apache big data projects.
> 
> == Known Risks ==
> 
> === Orphaned Products ===
> 
> The current product developers are all salaried developers at a small
> number of companies and thus there is a risk of becoming an orphaned
> product. However, the companies view Metron as very important to their
> product offering and plan to ramp up their work in the space. The project
> is unique in the product space and thus has strong potential to become a
> sustainable community.
> 
> === Inexperience with Open Source ===
> The vast majority of the developers are inexperienced with open source
> development and the Apache Way. One of the major hurdles to graduation from
> the Apache Incubator will be demonstrating that they have learned the
> Apache Way and are applying it to how the project is managed. Vinod Kumar
> Vavilapalli is an Apache Member and plans on actively working as a
> committer in the project. They also have the other mentors to help them
> learn as they progress.
> 
> === Homogenous Developers ===
> The developers are employed by four diverse companies (B23, Hortonworks,
> Mantech, and Rackspace), They are distributed across the United States. We
> hope to attract additional diversity as an Apache project.
> 
> === Reliance on Salaried Developers ===
> Metron is currently being developed exclusively by salaried developers, but
> the goal of coming to Apache is to form a community of users and developers
> that is much more diverse including non-salaried developers.
> 
> === Relationships with Other Apache Products ===
> Metron has a strong relationship and dependency with Apache Flume, Hadoop,
> HBase, Hive, Kafka, Spark, and Storm. Being part of Apache’s Incubation
> community could help with a closer collaboration among these projects and
> as well as others.
> 
> We note that although there is a superficial resemblance to Apache Eagle,
> which does security analysis of Hadoop audit events, the projects are
> significantly different. In particular, Metron is focused on analyzing
> network packet traffic and thus has a very different scope and scale of
> events than Eagle.
> 
> === An Excessive Fascination with the Apache Brand ===
> 
> While the Apache brand is important, we are much more interested in finding
> a home for the project that encourages open development and open
> governance. We want to form the new community using the Apache Way with its
> strong focus on meritocracy, organizational independence, and open
> development.
> 
> == Documentation ==
> The current information on the OpenSOC project is here:
> http://opensoc.github.io/
> A slide deck presenting background material is here:
> http://www.slideshare.net/JamesSirota/cisco-opensoc
> 
> == Initial Source ==
> The initial code is on github:  http://opensoc.github.io/
> 
> == External Dependencies ==
> Metron has the following external dependencies:
>  * Apache Flume
>  * Apache Hadoop
>  * Apache HBase
>  * Apache Hive
>  * Apache Kafka
>  * Apache Spark
>  * Apache Storm
>  * ElasticSearch
>  * MySQL
> 
> The project understands that it will need to support alternatives for MySQL
> that are licensed under a ALv2 compatible license.
> 
> == Cryptography ==
> Metron will eventually support encryption on the wire, but this is not one
> of the initial goals, and we do not expect Metron to be a controlled export
> item due to the use of encryption. Metron supports but does not require the
> Kerberos authentication mechanism to access secured Hadoop services.
> 
> == Required Resources ==
> 
> === Mailing List ===
> 
>  * metron-private for private PMC discussions
>  * metron-dev for developers
>  * metron-commits for all commits
>  * metron-users for all users
> 
> === Ve

Re: [VOTE] Release Apache Atlas 0.8 (incubating) RC1

[Vinod Kumar Vavilapalli]

Great work, Atlas community!

Looked at the release, albeit a little late, per my check-list. We can look at 
the Side notes lines for the next release.

 - Can compile from the release tag, skipping unit-tests: mvn clean install 
-DskipTests
   — Side notes: The compilation takes a long time, may be because I was 
starting off a relatively clean .m2
 - Creating the package: mvn clean package -DskipTests passes.
— The package name looks good: 
./distro/target/apache-atlas-0.8-incubating-sources.tar.gz / 
./distro/target/apache-atlas-0.8-incubating-bin.tar.gz
— Side notes: mvn package after mvn clean install fails.
 - Rat check is good
— mvn clean verify -DskipTests passes
— Side notes: Though I expected "mvn apache-rat:check” to work
 - Integrity
— KEYS present on 
https://dist.apache.org/repos/dist/dev/incubator/atlas/KEYS
— Checksum checks out. In Hadoop, we generate other hashes too via a .mds 
file (gpg2 --print-mds). For future.
— Release signatures look okay
 - LICENSE, NOTICE, DISCLAIMER files are located right
 - Side note: Publish info about maven artifacts for downstream users?

+1 binding.

Thanks
+Vinod

> On Mar 11, 2017, at 9:46 AM, Madhan Neethiraj  wrote:
> 
> Incubator PMC,
> 
> Apache Atlas community has voted on and approved the proposal to release 
> Apache Atlas 0.8 (incubating).
>  - vote result thread: 
> https://lists.apache.org/thread.html/f4bdc475b0de0278c51f7875838ab9b4ac3b83a70855007ca967891e@%3Cdev.atlas.apache.org%3E
>  - vote thread: 
> https://lists.apache.org/thread.html/c030c13ee931852f9d3e52647958e1e0cf740b5bdedca74500f119b2@%3Cdev.atlas.apache.org%3E
> 
> Apache Atlas 0.8 (incubating) release candidate #1 is now available for IPMC 
> vote. Please review and vote.
> 
> The vote will be open for at least 72 hours or until necessary number of 
> votes are reached.
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> Thanks,
> Madhan
> 
> 
> List of improvements and issues addressed in this release: 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20Atlas%20AND%20status%20%3D%20Resolved%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%200.8-incubating%20ORDER%20BY%20key%20DESC
> 
> Git tag for the release: 
> https://github.com/apache/incubator-atlas/tree/release-0.8-rc1
> 
> Sources for the release: 
> https://dist.apache.org/repos/dist/dev/incubator/atlas/0.8-incubating-rc1/apache-atlas-0.8-incubating-sources.tar.gz
> 
> Source release verification:
>  PGP Signature:  
> https://dist.apache.org/repos/dist/dev/incubator/atlas/0.8-incubating-rc1/apache-atlas-0.8-incubating-sources.tar.gz.asc
>  MD5 Hash:   
> https://dist.apache.org/repos/dist/dev/incubator/atlas/0.8-incubating-rc1/apache-atlas-0.8-incubating-sources.tar.gz.md5
> 
> Keys to verify the signature of the release artifacts are available at: 
> https://dist.apache.org/repos/dist/dev/incubator/atlas/KEYS
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

Re: Call for a new mentor for Apache Slider

[Vinod Kumar Vavilapalli]

I am from Hadoop PMC and am involved a bit in these transition.

If the idea is to continue doing bug-fix releases on Apache Slider incubator, 
you can count me in.

Thanks
+Vinod

> On May 24, 2017, at 11:14 AM, Gour Saha  wrote:
> 
> Apache Slider is at a transition phase from being an independent incubator 
> project into Apache Hadoop as a module. The Apache Slider and Apache Hadoop 
> team has been working together on this for the past 1 year or so. During this 
> transition the Apache Slider incubating code will continue to be supported, 
> of course with fewer releases mainly with bug fixes and no major features.
> 
> At this interesting phase in Apache Slider's lifecycle, we are occasionally 
> missing mentor sign-offs on our reports. So we are looking for an additional 
> mentor who can assist the Slider community and the project through the 
> remainder of this transition into Apache Hadoop.
> 
> Kindly let us know if you are interested in this role.
> 
> -Gour


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Request for write access to Apache Incubator Wiki

[Vinod Kumar Vavilapalli]

Hi,

I just volunteered to be a mentor for the Apache Slider incubator project. 
Please grant me write access to Apache Incubator Wiki.

My apache ID is vinodkv and my wiki user-name  
VinodKumarVavilapalli 
(old account but mysteriously deleted, just recreated it).

Thanks
+Vinod

Re: Request for write access to Apache Incubator Wiki

[Vinod Kumar Vavilapalli]

Thanks a bunch, Nick!

+Vinod

> On Jun 3, 2017, at 1:37 AM, Nick Burch  wrote:
> 
> On Fri, 2 Jun 2017, Vinod Kumar Vavilapalli wrote:
>> I just volunteered to be a mentor for the Apache Slider incubator project. 
>> Please grant me write access to Apache Incubator Wiki.
> 
> Karma granted, happy mentoring!
> 
> Nick
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Retire the Slider podling

[Vinod Kumar Vavilapalli]

+1 (binding).

With YARN services in Apache Hadoop 3.1 release, there is a good path forward.

Thanks
+Vind

> On May 20, 2018, at 10:59 AM, Billie Rinaldi  wrote:
> 
> After a long period of low activity, the Slider PPMC has recently decided
> upon retirement [1]. Please vote on whether we should retire the Slider
> podling. Here is my +1 (binding).
> 
> [ ] +1 Retire Slider
> [ ] +0 No opinion
> [ ] -1 Do not retire Slider because ...
> 
> This vote will remain open for 72 hours.
> 
> [1]: https://s.apache.org/V8SB


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] YuniKorn Proposal

[Vinod Kumar Vavilapalli]

Yup, on it.

Thanks
+Vinod

> On Jan 9, 2020, at 12:42 PM, 俊平堵  wrote:
> 
> Agree. Shall we call for a vote? @Vinod Kumar Vavilapalli 
> <mailto:vino...@apache.org> 
> 
> Thanks,
> 
> Junping
> 
> Justin Mclean mailto:jus...@classsoftware.com>> 
> 于2020年1月9日周四 上午7:59写道：
> Hi,
> 
> I think this discussion has died down and everything has been resolved and 
> you can call for a vote.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
> <mailto:general-unsubscr...@incubator.apache.org>
> For additional commands, e-mail: general-h...@incubator.apache.org 
> <mailto:general-h...@incubator.apache.org>
> 

[VOTE] Accept YuniKorn into Apache Incubator

[Vinod Kumar Vavilapalli]

Hi,

I'd like to call a vote on accepting YuniKorn into the Apache Incubator.

Please see the discussion thread [1].

Please see the full proposal: 
https://cwiki.apache.org/confluence/display/INCUBATOR/YuniKornProposal

Please cast your vote

[ ] +1 Accept YuniKorn into the Incubator
[ ] +0 Indifferent to the acceptance of YuniKorn
[ ] -1 Do not accept YuniKorn because …

The vote will be open at least for 72 hours.

Incubator PMC member votes are binding. Everyone else is welcomed to vote too 
(mark them as non-binding if you can)!

Thanks
+Vinod

[1] [DISCUSS] YuniKorn Proposal 
https://lists.apache.org/thread.html/59a3fc019119352f06e75a2bae5c25cd1b652282d7a59b85ed2188cf%40%3Cgeneral.incubator.apache.org%3E
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept YuniKorn into Apache Incubator

[Vinod Kumar Vavilapalli]

Quick final update on the follow-up process.
 
I got the mailing lists created through ASF Infra team: 
d...@yunikorn.apache.org, priv...@yunikorn.apache.org, 
iss...@yunikorn.apache.org

Mentors and initial committers, please subscribe using whimsy mailing list 
helper tool: https://whimsy.apache.org/committers/subscribe

JIRA is also created: 
https://issues.apache.org/jira/projects/YUNIKORN/issues/?filter=allopenissues

The rest of the communication will now move to the podling specific lists.

Thanks
+Vinod

> On Jan 21, 2020, at 8:05 PM, 俊平堵  wrote:
> 
> Hi,
> 
>The vote passes with 20 binding +1 votes and 10 non-binding +1 votes
> and no other votes.
> 
> 
> +1 (binding)
> 
> *Felix Cheung*
> 
> *Craig Russell*
> 
> *Furkan KAMACI*
> 
> *Michael Wall*
> 
> *Sheng Wu*
> 
> *Kevin Ratnasekera*
> 
> *Dave Meikle*
> 
> *Byung-Gon Chun*
> 
> *Jean-Baptiste Onofré*
> 
> *Justin Mclean*
> 
> *Vinayakumar B*
> 
> *Paul King*
> 
> *Dave Fisher*
> 
> *Liang Chen*
> 
> *Hitesh Shah*
> 
> *Bertrand Delacretaz*
> 
> *Arpit Agarwal*
> 
> *Kevin A. McGrail*
> 
> *Junping Du*
> 
> *Jason Lowe*
> 
> 
> 
> +1 (non-binding)
> 
> *David Lyle*
> 
> *Tison*
> 
> *YuanSheng Wang*
> 
> *Ming Wen*
> 
> *Brahma Reddy Battula*
> 
> *Jeff Zhang*
> 
> *Yiheng Wang*
> 
> *Junjie Chen*
> 
> *Rakesh Radhakrishnan*
> 
> *Supun Kamburugamuva*
> 
> 
> I am excited to welcome the YuniKorn community into the Apache Incubator.
> 
> 
> 
> *Thanks,*
> 
> 
> 
> 
> *Junping*
> 
> 
> 
> 俊平堵  于2020年1月20日周一 下午5:34写道：
> 
>> Agree with Justin. @Vinod Kumar Vavilapalli  , would
>> you like to do the honor?
>> 
>> Thanks,
>> 
>> Junping
>> 
>> Justin Mclean  于2020年1月19日周日 上午7:58写道：
>> 
>>> HI,
>>> 
>>> Probably about time this vote stoped and result announced?
>>> 
>>> Thanks,
>>> Justin
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org