This is a work in progress
Incubator document about writing a proposal, for information: https://incubator.apache.org/guides/proposal.html
brooklyn is a library that simplifies application deployment and management. For deployment, it is designed to tie in with other tools, giving single-click deploy and adding the concepts of manageable clusters and fabrics. Brooklyn makes roll-out an integral part of the DevOps chain, as code which can be version-controlled and programmatically tested, and portable across many clouds or fixed IP machines. Brooklyn's main emphasis is post-deployment, managing an application once it is live: management policies are an integral part of the deployment descriptor, and at runtime policies have access to all aspects of the deployment.
brooklyn is a library that simplifies application deployment and management.
For deployment, it is designed to tie in with other tools, giving single-click deploy and adding the concepts of manageable clusters and fabrics:
- many common software entities available out-of-the-box
- integrates with Apache Whirr -- and thereby Chef and Puppet -- to deploy well-known services such as Hadoop and elasticsearch (or use POBS, plain-old-bash-scripts)
- use PaaS's such as OpenShift, alongside self-built clusters, for maximum flexibility
Brooklyn makes roll-out an integral part of the DevOps chain, as code which can be version-controlled and programmatically tested, and portable across many clouds or fixed IP machines, using jclouds -- or just hitting localhost for quick dev/test.
Brooklyn's main emphasis is post-deployment, managing an application once it is live: management policies are an integral part of the deployment descriptor, and at runtime policies have access to all aspects of the deployment. They are aware of the deployment topology (hierarchical) and locations (machines, PaaSes, and jurisdictions), as well as scripts, instrumentation, and operational goals and constraints. This means they're all set, once the application is launched, to keep the application running optimally, based on whatever optimally means in that context.
These deployment patterns and management policies are expressed as Java (and Groovy) classes, open-sourced here and giving you full control over what you want to happen. More importantly, however, this code can be shared, improved, and extended.
[Provides context for those unfamiliar with the problem space and history.
Explain terms whose meanings may be misunderstood (for example, where there is not a single widely adopted definition).
This content should be capable of being safely ignored by domain experts. It should probably find an eventual home on the Podling website.]
[Explains why this project needs to exist and why should it be adopted by Apache. This is the right place for discursive material.]
[A complex proposal (involving multiple existing code bases, for example) may cause concerns about its practicality. A good way to address these concerns is to create a plan that demonstrates the proposal is feasible and has been carefully thought through.
Many projects will not need this section.]
[This section (and the contained topics) describes the candidate's current status and development practices. This should be an honest assessment balancing these against Apache's principles and development ideals.
For some proposals, this is a chance to demonstrate understanding of the issues that will need to addressed before graduation. For others, this is a chance to highlight the close match with Apache that already exists. Proposals without an initial code base should just simply state that.
Some proposals name this section criteria (though the term is a little misleading).]
We believe in the meritocracy principles. We welcome the opportunity for talented developers to become committers and join the PMC.
Brooklyn currently has a small community. We are starting to see more users discover the project, and there have recently been new names joining our mailing lists. It is important that we nurture this community, and attract more people to join our community.
[Apache is composed of individuals.
It is useful to provide a brief introduction to the developers on the initial committers list. This is best done here (and not in that section). This section may be used to discuss the diversity of the core development team.]
We wish Brooklyn to follow the best practices of open source, and Apache is a model of these practices.
Brooklyn is already using many Apache projects. In particular, jclouds is our most important dependency. CloudStack is proven to be a reliable deployment target for Brooklyn. And, Brooklyn is able to deploy many Apache projects.
The team behind Brooklyn firmly believe in their project, and are committed to its success. They will be pushing the project until, and beyond, its community makes the project self-sustaining.
Brooklyn has been open source since April 2012. All development has happened in public on GitHub, backed up by mailing lists on Google Groups. The team of committers are committed to the principles of open source, and count amongst their number existing Apache committers.
For some of the extended list of contributors more used to commercial development, the commitment to openness is a habit that still needs to be learnt. For example, there is a feeling that some things need to be discussed "internally" first. However this instinct is being un-learned as our experience with the project in open source form continues. Under the guidance of the initial committers, we do not expect this to become a serious risk.
The initial committers are all affilliated with Cloudsoft Corporation Ltd. Likewise, all of the commits to the project to date have been by Cloudsoft employees.
We do have a geographically distributed list of contributors; most of our contributors are from the United Kingdom, however we have a significant number of commits from people from other European countries and from the United States.
Our community is beginning to grow, and we hope to grow the community significantly and bring more diversity into the list of committers and PPMC members. However we recognise the current lack of diversity as a known risk.
The initial committers are all affilliated with Cloudsoft Corporation Ltd. Likewise, all of the commits to the project to date have been by Cloudsoft employees in the line of their work.
Our community is beginning to grow, and we hope to grow the community significantly and bring more diversity into the list of committers and PPMC members. However we recognise the reliance on salaried developers as a known risk.
Brooklyn has relationships to several other Apache projects:
- Brooklyn can deploy instances of Cassandra, Tomcat, HTTP Server, ActiveMQ, Qpid, Solr
- Brooklyn uses Whirr to deploy instances of Hadoop and HBase
- jclouds is our single most important dependency, which we use for virtually all our interaction with cloud provider APIs.
- CloudStack is a first-class target for Brooklyn application deployments, and we have used it on many occasions.
- We develop using the ubiquitous Maven and libraries such as HttpComponents and various Commons projects.
There is some overlap with the Whirr project; at face value, both Whirr and Brooklyn allow complex applications to be deployed into cloud providers. However our emphasis is different - Brooklyn provides policy-based management to monitor applications. In our minds we don't compete - in fact, we support the use of Whirr in Brooklyn to deploy Hadoop clusters.
We consider that Apache is a natural home for Brooklyn; we license our code under the Apache License, and we make extensive use of jclouds which recently graduated from the Apache incubator; we aspire to follow open source best practices. Our proposal to the Apache Incubator is based in pragmatism, not idolising.
Brooklyn's primary website is available at http://brooklyn.io/
[Describes the origin of the proposed code base. If the initial code arrives from more than one source, this is the right place to outline the different histories.
If there is no initial source, note that here.]
- https://github.com/brooklyncentral/brooklyn
- https://github.com/brooklyncentral/brooklyn-examples
- https://github.com/brooklyncentral/brooklyncentral.github.com
- https://github.com/brooklyncentral/camp-server
TODO: include these?
- https://github.com/brooklyncentral/brooklyn-hackathon-hello
- https://github.com/brooklyncentral/brooklyn-play-framework
The code is licensed under Apache License V2, and all contributions are subject to an Apache-style ICLA with Cloudsoft Corporation Ltd. Cloudsoft will transfer all its rights in the Brooklyn code to the Apache Foundation.
In addition to the code, Cloudsoft has registered a trademark on the name "Brooklyn", and the logo currently used for the project. These will also be donated to the Apache Foundation.
There are also a number of other assets related to the project, such as its domain name, Twitter account, and IRC channel. During incubation we expect to identify all the assets currently owned or controlled by Cloudsoft, and arrange the transfer, replacement, or deprecation of these assets as appropriate.
[External dependencies for the initial source is important. Only some external dependencies are allowed by Apache policy. These restrictions are (to some extent) initially relaxed for projects under incubation.
If the initial source has dependencies which would prevent graduation then this is the right place to indicate how these issues will be resolved.]
Brooklyn does not directly implement cryptography code. It may rely on other projects to perform certain cryptographic tasks (e.g. calculating signatures for requests to cloud providers.)
We currently have "dev" and "user" lists hosted by Google Groups; we would like to replicate these lists at Apache and deprecate the Google Groups lists.
In alignment with Apache's standard practices, we would also have a "private" list for the PMC members, and a "commits" list.
We are currently using git repositories, and we would prefer to continue using git in Apache. We would require repositories with the following names:
- brooklyn
- brooklyn-examples
- camp-server
TODO: something for the website?
TODO: include these?
- brooklyn-hackathon-hello
- brooklyn-play-framework
[options are jira or bugzilla]
We would prefer to use Jira, with a project name of "BROOKLYN".
No other resources are required at this time.
Cloudsoft currently provide Jenkins continuous integration for Brooklyn; we would expect that this is moved to Apache's continuous integration service at some point, but we do not require this in the short term.
TBD, will be similar to the Brooklyn Central team
All the commits to the project so far have been made by people who were employees of Cloudsoft Corporation Ltd at the time of the contribution, and the vast majority of those commits were in the line of their employment.
As stated in the Known Risks section, we appreciate that this cannot continue long term, and encouraging people not affiliated with Cloudsoft to join the project as committers and PMC members will be a key goal of the project.
Chip Childers chipchilders@apache.org has kindly volunteered to champion Brooklyn in the Incubator.
Aside from our Champion, we have no additional Mentors in mind at this stage. We recognise the value that Mentors provide and appreciate that 3-5 Mentors greatly assists the incubation process, and would welcome these Mentors.
We propose that the Incubator sponsors the Brooklyn podling.