Difference between revisions of "ReddwarfAppliesForIncubation"

Revision as of 17:47, 18 April 2013

Project codename:

RedDwarf

Summary:

A control plane for managing multiple database technologies.

Detailed Description:

Reddwarf is Database as a Service for Openstack. It's designed to run entirely on OpenStack, with the goal of allowing users to quickly and easily utilize the features of a database without the burden of handling complex administrative tasks. Cloud users and database administrators can provision and manage multiple database instances as needed. The service focuses on providing database resource isolation while automating complex administrative tasks including deployment, configuration, patching, backups, restores as well as horizontal and vertical scaling. While initially focused on MySQL, the future of Reddwarf will support multiple database technologies, including relational (SQL) and non-relational (NoSQL) technologies such as Redis, MongoDB, MariaDB, PostgreSQL, etc.. The long-term vision for Reddwarf is to provide a framework to control any persistant database management system.

Today, Reddwarf is a consumer of OpenStack. It is built on and leverages core OpenStack infrastructure services. It allows a service provider the flexibility of deployment and configuration of the core OpenStack components, and uses those components as the building blocks of its service. This includes Keystone for auth, Nova for instance creation, Cinder for volume support, Glance for images, Swift to store backups, and networking. In the future, we hope to eventually consume Ceilometer for metrics and Heat for initial image creation/orchestration, and potentially bare metal to spin up Reddwarf instances for the infrastructure database(s) within a Nova on Nova install.

With the recent adoption of Heat as an integrated project in OpenStack, many will question the need for a defined database service as Heat can orchestrate the setup of complex database clusters as well as handle basic lifecycle management of the database cluster. However, this is only one piece of a managing a database at scale. Reddwarf is layer above Heat, and as the project evolves, we will be able to leverage Heat to set up the database management system, which fits perfectly into our goal of leveraging core OpenStack services. The main differentiator for persistent datastores is that they require tightly integrated and specific operations such as controls to efficiently execute/schedule backups, restore a database to a specific point in time, configuration and optimization of the database, maintenance and management of data replication (masters and slaves) for horizontal scalability, and other database management tasks. A persistent datastore, clustered or not, is not simply a fire and forget resource. It needs constant monitoring and maintenance and we want to use this as the differentiator between Reddwarf and a service for orchestrating the creation of OpenStack resources. However, as Heat continues to evolve, and some basic lifecycle management tasks can be executed through it, we will have the option to leverage those operations.

Basic roadmap for the project:

Reddwarf can currrently deploy multiple mysql implementations. The API is evolving with new features, but as it stands is very stable in its implementation for the basic tasks. In the codebase as it stands today, both stock mysql and percona mysql are supported. The system is built such that multiple technologies can be leveraged, from the datastore implementation itself, to the tools used to keep maintenance ongoing. For instance, the backup feature, which is inflight, allows the cloud deployer to choose mysqldump or xtrabackup to backup the datastore.

From a datastore perspective, Reddwarf's functionality currently is the ability to spin up secured mysql databases, create/destroy schemas and users, and enable a root user. From a openstack project perspective, Reddwarf also has quota and limit support and consumes Oslo to build out the architecture of the api.

Reddwarf has a healthy backlog of features in order to fufil mysql features. Some of the inflight features are configuration (my.cnf) edits, manual backups and restores, notifications. Others that are not yet started include automated backups, including point in time restores, API types/versions, full featured user modification, and replication. This does not encompass all features. The current roadmap can be viewed as blueprints on launchpad.

There are also many housekeeping blueprints to maintain parity with other openstack projects. Reddwarf has strived to keep in line with the ecosystem, but there are some things that are necessary, such as completing integration with devstack. As it stands, reddwarf is integrated as much as possible today, and uses local.sh to instrument the reddwarf infrastructure. It also currently uses vm-gating and runs functional tests on every review.

Location of project source code:

Reddwarf operates like any other openstack project. Blueprints are registered and approved in the same fashion as the other projects, release cycles are followed, and code is gated through unit tests and functional tests. The codebase is in stackforge. Reviews are in openstack gerrit.

Programming language, required technology dependencies:

Python. pypi dependencies are listed in pip-requires and test-requires.

Is project currently open sourced? What license?:

Yes. Apache 2.0.

Level of maturity of software and team:

The team has followed the openstack ecosystem for a long time. They are well versed in understanding the ecosystem and follow it as closely as possible. Weekly meetings are held, a presence is always in irc, reviews are thoroughly picked through, and they hold a high standard for all code that lands in master. All features require unit and functional tests, and gating is done on these thru openstack jenkins and a external jenkins for said functional tests. The software is run in production currently by rackspace on thousands of nodes.

Proposed project technical lead and qualifications:

Michael Basnight (hub_cap on irc). Michael has lead the project since its inception at rackspace. He was the lead of the internal project, but has shifted his role within Rackspace to be fully dedicated to lead the public project. He is focused on the quality of the API, infrastructure, and testability of the project. He follows the openstack community closely and has contributed greatly to the project. He currently manages blueprints, runs the weekly meetings, and evangelizes reddwarf in the community. He has spoken at many of the OpenStack conferences and has attended almost all of the conferences since reddwarf began within Rackspace.

Other project developers and qualifications:

Currently HP and Rackspace contribute to the reddwarf project. They operate as a joint team within the open. They are listed below.

Tim Simpson (grapex on irc). Tim has worked on Reddwarf since its inception and wrote the initial tests; since then he has worked to ensure every feature reaching trunk is backed by solid testing. Following Mike's transition he has become the lead of the Rackspace Cloud Database product.

Vipul Sabhaya (vipul on irc). Vipul has been involved with reddwarf since 2011. He led the effort to get HP Cloud database as a service, based on Reddwarf launched. Vipul also led HP's efforts to refocus all development to the Reddwarf reference implementation. He has also promoted reddwarf by giving talks at the openstack summit, and is a member of the core team.

Nikhil Manchanda (slicknik on irc). Nikhil has been involved with OpenStack and reddwarf since 2012. He has led the effort on integrating reddwarf setup with devstack and has also worked on aligning reddwarf testing, packaging, and CI with OpenStack standards. He has worked on all parts of the reddwarf project, including the API, taskmanager, guestagent, client, and documentation.

Jim Cooley. Jim has been involved with reddwarf since 2012, He has led the efforts to launch multiple Openstack related projects: DNS (moniker), Messaging, Load Balancing, and Monitoring. He initiated the HP move to the Reddwarf reference implementation and abandonment of their proprietary codebase and the migration into the Devstack gate (with the sponsorship of Monty Taylor, checkin currently on hold).

Anna Shen (annashen on irc). Anna has been involved with reddwarf since late 2011. She worked primarily on SmartAgent of HP Reddwarf 1.0 and Packaging Reddwarf, she now works on GuestAgent and API side.

Dan Nguyen (esp on irc). Dan has been working on Reddwarf since 2012 and contributes code to the reddwarf API, python-reddwarf-client, and reddwarf-integration. He's also started to look at other openstack projects as necessary to support Reddwarf development.

Steve Leon (esmute on irc). Steve has been involved with reddwarf since 2012, and has been contributing to both reddwarf and its client.

Saurabh Surana (saurabhs on irc) Saurabh has been involved with reddwarf since 2012. He mainly works on running reddwarf for HP's cloud.

Robert Myers (robertmyers on irc). Robert has been involved with Reddwarf since late 2012. He has contributed to the API and integration tests for Reddwarf. He has also contributed to the Openstack Olso project.

DJ Johnstone (djohnstone on irc). DJ has been involved with Reddwarf since late 2011. He was the Test Lead for Rackspace Cloud Database for most of 2012 and transitioned over to development on the team in Nov.

Joe Cruz (jcru on irc). Joe has been involved with Reddwarf since 2012. He is currently a Software Developer on the Cloud Database team at Rackspace.

Ed Cranford (datsun180b on irc). He has been involved with Reddwarf since mid 2011. He is also a Software Developer on the Cloud Database team at Rackspace, contributing to reddwarf and the client.

Daniel Salinas (imsplitbit on irc) Co-inventor of reddwarf project. Software Developer on the Cloud Database team at Rackspace currently working on extending Nova with OpenVz functionality. He has over five years of DBA experience.

GUYS::::: INSERT YOUR QUALS HERE :::::::

Infrastructure requirements (testing, etc):

Reddwarf has built its own testing environment. Its currently run as a gating job within by jenkins. Tox runs pep8 and unit tests on each commit through openstack gerrit. The reddwarf developers understand that, over time, they will adopt the openstack testing frameworks for all new functional tests. The core of reddwarf is run on openstack and installed within devstack. Reddwarf-integration, a project on stackforge, controls the installation and setup of reddwarf for development and testing. Tests are run in a openstack/kvm environment.

Have all current contributors agreed to the OpenStack CLA?

Yes.