Project logistics
- Mentor:
- George Silvis gsilvis-at-bu-dot-edu
- Min-max team size: 4-7
- Expected project hours per week (per team member): 6-8
- Will the project be open source? Yes, under the Apache license, possibly with the goal of being integrated into OpenStack.
Preferred past experience
Some experience in one or more of the following is preferred in possible team members:
- Python
- Openstack
The Massachusetts Open Cloud
Currently, cloud providers, such as Amazon and Rackspace, offer all of their cloud services themselves: compute (VMs), virtual disks, data storage, networking, and so on. Users are therefore locked in to one solution---they cannot combine data storage from Rackspace with compute from Amazon.
The Massachusetts Open Cloud (MOC) is trying to create an environment where multiple cloud service providers offer different services, and users can combine different provider's services at their choice.
Openstack Resellers
Openstack services, such as Nova, Cinder, and Swift, are run by a resource provider (the group running and maintaining the Openstack installation), and used by a resource consumer (tenants in the Openstack installation). There is only two different economic roles in this system: the buyer and the seller.
For more complex systems, such as in the MOC, organizations may want to act as resellers: buying a resource, somehow repackaging it conveniently, and then selling it again. In an Openstack environment, this can be accomplished by running an Openstack service which itself gets its resources from other Openstack services.
In this project we will demonstrate one particular version of this: per-tenant pass-through openstack services. When you create or allocate an object in one of these services, it will pass the request to an underlying service, thereby creating or allocating the object there.
Extensions
At first, the pass-through implementations will be hard-coded for simplicity to use one particular underlying service. The next step is to use the MOC Service Directory to discover the relevant services, and allow the user to select some (possibly restricted) combination of them.
Another related project is the MOC client library. It is designed to be a general API for cloud applications intended to run in the MOC. It would abstract over different backends, by letting the user choose which services to use, but then have the user interact with those different options in one uniform way. This project is related, in that it achieves some of the same goals, but without forcing users to modify their cloud services. So, another goal is to make a version of the Openstack pass-through services that is based on the MOC client library.
Finally, for using these pass-through services to be convenient, there should be a way to deploy these pass-through services in an automated fashion, possibly using Heat. (The MOC client library has this goal as well, and some work could be shared there.)
Possible Goals
- Write a pass-through implementation for some of the Openstack
services (most likely Nova)
- Decide how to manage authorization and authentication---use the underlying layer's identity services, or build new ones
- One-to-one or many-to-one?
- In the many-to-one situation, does there need to be metadata for which underlying service to go to? Do Openstack APIs need to be modified?
- Multiple backends
- Discovering backends in the MOC service directory
- Establishing a way to select particular backends
- Integration with MOC client library
- Automated deployment of pass-through services
Some Technologies Expected To Be Learned/Used
- Python
- Openstack APIs
- Automated deployment of infrastucture in Openstack