Re: [VOTE] Accept Twill for Incubation
+1 (non-binding) On Fri, Nov 8, 2013 at 6:40 PM, Andrew Purtell apurt...@apache.org wrote: +1 (non-binding) On Thu, Nov 7, 2013 at 1:04 PM, Andreas Neumann a...@apache.org 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
Re: please follow through to publish doc changes
Jake, thank you for taking care of that! I didn't see anything on the Knox mailing list - should I have? Can you tell me exactly what was fixed and where? We will be sure to investigate what went wrong and document the proper procedure going forward. Is there anything that is outstanding that is still needed from the Knox community? Thanks, --larry On Tue, Oct 29, 2013 at 11:42 PM, Jake Farrell jfarr...@apache.org wrote: I went ahead and fixed the missing /li tag Knox had and this should resolve the issue you saw David. I also have cleaned up some of the issues seen on the voter status page and I just saw that Olivier Lamy committed the batchee.xml missing project status page (Thanks Olivier). All changes are published and on the incubator website -Jake On Tue, Oct 29, 2013 at 9:19 PM, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Oct 29, 2013 at 5:12 PM, David Crossley cross...@apache.org wrote: This continues to be a problem. It is now exacerbated because someone has made source content errors (knox) but because people do not bother to try to publish changes, these errors are not noticed or attended to. It is preventing other people from working. Same with podlings.xml. I don't suppose DeltaSpike is ever going to perform the post-graduation cleanup -- they're going to be getting incubating reporting reminders forever. Also, somebody's dropped the ball with BatchEE. Marvin Humphrey - 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.
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
+1 (non-binding) On Tue, Oct 1, 2013 at 1:09 AM, Lieven Govaerts lieven.govae...@gmail.comwrote: On Mon, Sep 30, 2013 at 9:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. +1 (non-binding) I hope to be able to contribute to this project during incubation. Lieven - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
I was under the impression that what you describe was the policy - if it is not then is should certainly be clarified. In the event that podlings continue to or are to be given such a choice, I believe that there needs to be a clear understanding between the incoming community and those volunteers that are shepherding them through the process as to what the choice is and some of the nuances that will be encountered in the execution. If there is no choice there then this consensus step is less necessary and the process can be more easily executed by the champion, mentors and incoming community. That shared understanding seems to be what was missing in this case. On Wed, Sep 25, 2013 at 1:06 PM, Dave snoopd...@gmail.com wrote: Or better yet, a change like that could be made to the Incubator Policy. http://incubator.apache.org/incubation/Incubation_Policy.html Thoughts? - Dave On Wed, Sep 25, 2013 at 1:01 PM, Dave snoopd...@gmail.com wrote: How do we go about changing the Incubator Proposal Guide so that the rules around adding new committers to a podling at proposal time? As much fun as a good email thread can be, we don't want to have to relive the same ones over and over. Can we come up with a consensus view and get it into the guide here? http://incubator.apache.org/guides/proposal.html#template-initial-committers Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? What's the process for getting a change like this into the guide? Thanks, Dave
Re: The podling initial committers issue
I propose that this then be seen as a learning experience and determine what questions a champion needs to ask of the mentors and incoming community on the outset in order to execute. This has been an unfortunate bit of thrashing that was avoidable through communication. That is not to say that it is anyone's fault or anyone is right or wrong. We just need the champion/mentor survey questions established. On Wed, Sep 25, 2013 at 2:09 PM, Jim Jagielski j...@jagunet.com wrote: On Sep 25, 2013, at 1:33 PM, larry mccay larry.mc...@gmail.com wrote: That shared understanding seems to be what was missing in this case. Indeed that was the case, as I indicated in a previous post. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator
+1 (non-binding) Good luck! I would be interested in being a committer on user-grid due to the synergies that seem possible between Apache Knox (incubating) and user-grid. If this is something that you would welcome then I would be happy to join as an initial committer. Regardless, good luck and enjoy! On Tue, Sep 24, 2013 at 12:57 PM, Senaka Fernando sen...@apache.org wrote: +1 (binding) Thanks, Senaka. On Tue, Sep 24, 2013 at 6:49 PM, Olivier Lamy ol...@apache.org wrote: +1 On 23 September 2013 22:44, Jim Jagielski j...@jagunet.com wrote: After a useful and successful proposal cycle, I would like to propose a VOTE on accepting Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. Voting to run for 72+ hours... Here is a link to the proposal: https://wiki.apache.org/incubator/UsergridProposal It is also pasted below: = Usergrid Proposal = == Abstract == Usergrid is a multi-tenant Backend-as-a-Service stack for web mobile applications, based on RESTful APIs. == Proposal == Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services (user registration management, data storage, file storage, queues) and retrieval features (full text search, geolocation search, joins) to power common app features. It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment. For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise. == Background == Developing web or mobile applications obviously necessitates writing and maintaining more than just front-end code. Even simple applications can implicitly rely on server code being run to store users, perform database queries, serve images and video files, etc. Developing and maintaining such backend services requires skills not always available or expected of app development teams. Beyond that, the proliferation of apps inside of companies leads to the creation of many different, ad-hoc, unequally maintained backend solutions created by employees and contractors alike and hosted on a wide variety of environments. This is causing poor resource usage, operational issues, as well as security, privacy compliance concerns. In response to this problem, companies have long tried to standardize their server-side stack or unify them behind an ESB or API strategy. Backends-as-a-Service follow a similar approach but their unique characteristic is strongly tying 1) a persistence tier (typically a database), 2) a server-side application tier delivering a set of common services and 3) a set of client-side application interface mechanisms. For example, a BaaS could package 1) MongoDB with 2) a node.js application that offers access through 3) WebSockets. In the case of Usergrid, the trifecta is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API. The Backend-as-a-Service approach has steadily gained popularity in the last few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com, each operating tens of thousands of apps for tens of thousands of developers. The trend has already reached large organizations as well, with global companies such as Korea Telecom internally building a privately-run BaaS platform. But so far, there have been limited options for developers that want a non-proprietary, open option for hosting and providing these services themselves, or for enterprise and government users who want to provide these capabilities from their own data centers, especially on a very large scale. == Rationale == The issue this proposal deals with is implicit in the name. Backend-as-a-Service platforms are usually offered solely as proprietary cloud services. They are typically closed sourced, hosted on public clouds, and require subscription payment. Usergrid opens the playing field, by making a fully-featured BaaS platform freely available to all. This includes developers that previously could not afford them, such as mobile enthusiasts, small boutiques, and cost-sensitive startups. This also includes large companies that benefit from
Re: [VOTE]: Accept Sentry in Apache Incubator
+1 (non-binding) On Aug 5, 2013, at 9:23 AM, Shreepadma Venugopalan shreepa...@cloudera.com wrote: Following the discussions last week, I'm calling a vote to accept Sentry as a new project in the Apache Incubator. The proposal draft is available at: https://wiki.apache.org/incubator/SentryProposal and is also pasted to the bottom of this email. It is identical to what was proposed except for a) addition of two new mentors, and b) removal of the user list for now, per Marvin's suggestion. The proposal thread is available at: http://goo.gl/bvvJPh [ ] +1 Accept Sentry in the Incubator [ ] +/-0 Don't care [ ] -1 Don't accept Sentry in the Incubator because... Thanks. Shreepadma = Sentry - A fine-grained Authorization System for the Hadoop ecosystem = == Abstract == Sentry is a highly modular system for providing fine grained role based authorization to both data and metadata stored on an Apache Hadoop cluster. Sentry can be used to enforce various access policy rules when accessing data stored on Hadoop Distributed File System through various Hadoop ecosystem components such as Apache Hive, Apache Pig or others. == Proposal == Traditionally, user access control in Apache Hadoop has been implemented using file based permissions on HDFS. Following the UNIX permissions model, HDFS offers all or nothing semantics allowing administrator to configure system to allow certain users or user groups read, write or perform both operations on files. This system does not enable more fine grained permissions that allow access policies for logical parts within one file. Furthermore, this model can't be used to restrict access to the rich set of objects in the metadata catalog that are stored outside HDFS. Sentry will provide true role-based fine-grained user access control for Apache Hadoop and its ecosystem components such as Hive, Pig or HBase. This includes providing fine- grained role based access to both data as well as the metadata, which provides a rich object based abstraction such as databases, tables or columns. == Background == Sentry was initially developed by Cloudera to allow users fine grained access to data as well as the metadata in Apache Hadoop. Sentry has been maintained as an open source project on Cloudera’s github. Sentry was previously called “Access”. All code in Sentry is open source and has been made publicly available under the Apache 2 license. During this time, Sentry has been formally released two times as versions 1.0.0 and 1.1.0. == Rationale == Currently, users don't have a way to achieve fine grained enforceable user access control to data stored in HDFS and their associated metadata. While users can use file based permissions to control access to specific directories and files, it is insufficient because access can't be restricted to file parts i.e., to specific lines or logical columns. In the absence of such support, users have to resort to duplicating data. Furthermore, file based permissions are insufficient to provide any form of access control to the metadata that provides an object abstraction such as databases, tables, columns or partitions over the data stored in HDFS. Current Sentry developers subscribe to the mission of ASF and are familiar with the open source development process. Several members are already committers and PMC members of various other Apache projects. == Initial Goals == Sentry is currently in its first major release with a considerable number of enhancement requests, tasks, and issues recorded towards its future development. The initial goal of this project will be to continue to build community in the spirit of the Apache Way, and to address the highly requested features and bug-fixes towards the next dot release. == Current Status == === Meritocracy === Intent of the proposal is to build a diverse community of developers around Sentry. Sentry started as a open source project on Github, driven in the spirit of open source and we would like to continue in this spirit by, for example, encouraging contributors from a variety of organizations. === Community === Sentry stakeholders desire to expand the user and developer base of Sentry further in the future. The current sets of developers in Sentry are committed to building a strong user base and open source community around the project. Development discussions within the current team have been on a public mailing [[ https://groups.google.com/a/cloudera.org/forum/#!forum/access-dev | list]]. === Core Developers === The core developers for the Sentry project are Brock Noland, Shreepadma Venugopalan, Prasad Mujumdar and Jarek Jarcec Cecho. Other contributors include Arvind Prabhakar and Xuefu Zhang. All engineers have deep expertise in Hadoop and various other ecosystem components. === Alignment === Sentry complements the access control feature of some projects in the Apache
Re: [PROPOSAL] Sentry for Incubator
Correction: I am a member of the PPMC for Knox - sorry for the typo in my previous reply. On Tue, Jul 30, 2013 at 5:07 PM, Larry McCay lmc...@hortonworks.com wrote: Hi Shreepadma - Interesting work. Given some more diversity on the mentor list, I would give a +1. Being on the IPMC for Knox, I can easily imagine Sentry and Knox being complementary to each other and look forward to contributing to and/or leveraging this work within Knox. I'd be interested in throwing around some ideas for Knox and Sentry assuming you get accepted into the incubator. We can start discussions on either list - once established. thanks, --larry On Jul 30, 2013, at 3:40 PM, Shreepadma Venugopalan shreepa...@cloudera.com wrote: Thanks for your feedback, Bertrand. At this time, we are talking to a few other people to be mentors. If you're interested in being a mentor for Sentry, please drop me a line directly. No promises though, because it will be a collective decision. Regards. Shreepadma On Tue, Jul 30, 2013 at 12:39 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Tue, Jul 30, 2013 at 12:58 AM, Shreepadma Venugopalan shreepa...@cloudera.com wrote: ... === Nominated Mentors === * Arvind Prabhakar (Cloudera) * David Nalley (Citrix) * Patrick Hunt (Cloudera) * Tom White (Cloudera) ... IMO a more diverse set of mentors affiliations would be better, any volunteers? -Bertrand - 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: [PROPOSAL] Sentry for Incubator
Hi Shreepadma - Interesting work. Given some more diversity on the mentor list, I would give a +1. Being on the IPMC for Knox, I can easily imagine Sentry and Knox being complementary to each other and look forward to contributing to and/or leveraging this work within Knox. I'd be interested in throwing around some ideas for Knox and Sentry assuming you get accepted into the incubator. We can start discussions on either list - once established. thanks, --larry On Jul 30, 2013, at 3:40 PM, Shreepadma Venugopalan shreepa...@cloudera.com wrote: Thanks for your feedback, Bertrand. At this time, we are talking to a few other people to be mentors. If you're interested in being a mentor for Sentry, please drop me a line directly. No promises though, because it will be a collective decision. Regards. Shreepadma On Tue, Jul 30, 2013 at 12:39 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Tue, Jul 30, 2013 at 12:58 AM, Shreepadma Venugopalan shreepa...@cloudera.com wrote: ... === Nominated Mentors === * Arvind Prabhakar (Cloudera) * David Nalley (Citrix) * Patrick Hunt (Cloudera) * Tom White (Cloudera) ... IMO a more diverse set of mentors affiliations would be better, any volunteers? -Bertrand - 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: [MENTOR] Re: Missing Release Distribution in Clutch Status?
Great! Thanks for the quick response and sorry for missing that on the page. We will remedy the naming convention issue. On Thu, Jun 20, 2013 at 10:05 PM, David Crossley cross...@apache.orgwrote: Mattmann, Chris A (398J) wrote: Hey Guys, Sorry I missed this. Real quick CC to general@i.a.o. I'm not an expert in the Clutch. IPMC peeps that know the clutch, Knox has a release in the dist area: http://www.apache.org/dyn/closer.cgi/incubator/knox/ (^^ for example the 0.2.0 release) Can someone give us some insight as to why the clutch indicates we don't have a release in the distro area? See the Knox entry in the Other issues section: http://incubator.apache.org/clutch.html#other It is because Knox is missing the required file naming convention: http://incubator.apache.org/clutch.html#h-hasRelease So the cron job that scans for releases does not find it. -David Thank you! Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: larry mccay larry.mc...@gmail.com Reply-To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Date: Thursday, June 20, 2013 11:46 AM To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Subject: [MENTOR] Re: Missing Release Distribution in Clutch Status? adding mentor prefix... On Mon, Jun 17, 2013 at 3:40 PM, larry mccay larry.mc...@gmail.com wrote: Touching this to bring it back to the top... @Chris - do you have any insight into this status indicator for us? On Thu, Jun 13, 2013 at 2:51 PM, larry mccay larry.mc...@gmail.comwrote: Here is the location of ambari - who has a true for release bits column - of course this is just one mirror - not sure how to map the mirrors: http://www.us.apache.org/dist/incubator/ambari/ambari-0.9-incubating/ relative path seems to map correctly to me... On Thu, Jun 13, 2013 at 2:32 PM, Kevin Minder kevin.min...@hortonworks.com wrote: We do have release bits in http://www.apache.org/dist/**incubator/knox/0.2.0/ http://www.apache.or g/dist/incubator/knox/0.2.0/ I wonder if they need to be in the root? On 6/13/13 1:29 PM, larry mccay wrote: All - This page shows the status of clutch currently in incubation. It indicates that we don't have a release in our distribution area. Does this mean that we don't have our release in the right place? http://incubator.apache.org/**clutch.html http://incubator.apache.org/ clutch.html thanks, --larry - 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
