Jump to: navigation, search

Difference between revisions of "ReddwarfAppliesForIncubation"

(Other project developers and qualifications:)
(Other project developers and qualifications:)
Line 63: Line 63:
  
 
'''Steve Leon (esmute on irc)'''. Steve has been involved with reddwarf since 2012, and has been contributing to both reddwarf and its client.
 
'''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.
  
 
GUYS::::: INSERT YOUR QUALS HERE :::::::
 
GUYS::::: INSERT YOUR QUALS HERE :::::::

Revision as of 06:08, 18 April 2013

Project codename: reddwarf

Summary (one sentence abstract of the project): 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. Initially, the service will focus on providing resource isolation at high performance while automating complex administrative tasks including deployment, configuration, patching, backups, restores, and monitoring. The future of Reddwarf will consume multiple database technologies, including relational and non relational technologies. The vision is for Reddwarf to control any datastore that requires ongoing maintanence, data integrity, and replication.

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 quantum for networking. We hope to eventually consume cielometer for metrics and heat for initial image creation, and potentially bare metal to spin up reddwarf instances for the infastructure database(s) within a nova on nova install.

One may ask how is this different from Heat. We will consume heat to set up a initial mysql datastore, which fits perfectly into our vision for using openstack services. The main differentiator for datastores is that they require specific maintainence to back up, restore, and keep continued maintainence of replication, slaves, and yet to be determined management tasks. A datastore is not simply a fire and forget resource. It needs constant monitoring and we want to use this as the differentiator between reddwarf and a service for spinning up fire and forget resources. As heat continues to evolve, and some maintanence tasks can be done through it, such as upgrades and restarts, we will consume those services. Our goal is to focus on the specifics of keeping a datastore online and use other projects as much as possible for the smaller tasks.


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 maintiannce 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 tess 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.

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.

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.