Difference between revisions of "Nova"
| Line 3: | Line 3: | ||
The purpose of this document is to capture the pluses and minuses of using Nova's code as a part of Cloud servers v2 | The purpose of this document is to capture the pluses and minuses of using Nova's code as a part of Cloud servers v2 | ||
| − | === | + | === What's Done === |
| − | * Scalable architecture | + | * Scalable and elastic architecture - fully message based and asynchronous |
* Many months ahead of us | * Many months ahead of us | ||
* written in good Python | * written in good Python | ||
* open source and it appears that they will be following an open development model | * open source and it appears that they will be following an open development model | ||
* have stubbed out all components for testing | * have stubbed out all components for testing | ||
| + | * Actually write SSH keys and authorized_keys properly | ||
| + | * All functionality is created via an adapter model, so implementations (for instance, storage backends, messaging backends, etc) can be swapped out as needed | ||
| − | === | + | === What Needs to be Done === |
| − | * | + | * Detach from Amazon/Eucalyptus specifics and make some things more generic |
| − | * | + | ** AOE |
| − | * Only supports | + | *** Definitely needs to be adapted for other services like [[CloudFiles]], gluster, etc |
| − | * Requires use of euca2ools, which are tainted. | + | * Defaults of VLANs could be changed |
| + | ** though you can manually allocate IPs or use DHCP (see /compute/network.py) | ||
| + | * Functionality needed by hosting providers | ||
| + | ** Metrics | ||
| + | *** CPU, memory, disk usage, network RX/TX | ||
| + | *** but, again, the backend storage is already taken care of... | ||
| + | * Billing | ||
| + | ** Need to define the billable events in a model | ||
| + | * Admin client is AWS-specific and needs an adapter interface | ||
| + | ** see /adminclient.py | ||
| + | * Only supports AMIs | ||
| + | * Requires use of euca2ools, which are tainted | ||
| + | * Overarching documentation is sparse (though the code comments are pretty decent) | ||
| + | * twisted (and Python) is, by nature, single-core, so it *may* be a bottleneck, but that remains to be demonstrated | ||
| + | * No support for gluster or drbd, but there are adapters for plugging such functionality into the app domain | ||
| + | * Add an endpoint so different compute clusters can be discovered for different clusters, especially when distributed geographically. | ||
| + | * Configuration management is almost non-existent | ||
| + | ** Need to plugin/adapt the configuration retrieval | ||
| + | ** Puppet, Chef, or even a DKVS | ||
| + | ** The "flavors" are hardcoded in /compute/node.py (grep for INSTANCE_TYPES) | ||
| + | |||
| + | === Unknowns === | ||
| + | |||
| + | * Asked jm to take a looksie into any possible Windows issues with the code base | ||
| + | ** We know that ssh keys will not work with windows, so another method is necessary | ||
Revision as of 19:25, 9 June 2010
Nova Cloud Review
The purpose of this document is to capture the pluses and minuses of using Nova's code as a part of Cloud servers v2
What's Done
- Scalable and elastic architecture - fully message based and asynchronous
- Many months ahead of us
- written in good Python
- open source and it appears that they will be following an open development model
- have stubbed out all components for testing
- Actually write SSH keys and authorized_keys properly
- All functionality is created via an adapter model, so implementations (for instance, storage backends, messaging backends, etc) can be swapped out as needed
What Needs to be Done
- Detach from Amazon/Eucalyptus specifics and make some things more generic
- AOE
- Definitely needs to be adapted for other services like CloudFiles, gluster, etc
- AOE
- Defaults of VLANs could be changed
- though you can manually allocate IPs or use DHCP (see /compute/network.py)
- Functionality needed by hosting providers
- Metrics
- CPU, memory, disk usage, network RX/TX
- but, again, the backend storage is already taken care of...
- Metrics
- Billing
- Need to define the billable events in a model
- Admin client is AWS-specific and needs an adapter interface
- see /adminclient.py
- Only supports AMIs
- Requires use of euca2ools, which are tainted
- Overarching documentation is sparse (though the code comments are pretty decent)
- twisted (and Python) is, by nature, single-core, so it *may* be a bottleneck, but that remains to be demonstrated
- No support for gluster or drbd, but there are adapters for plugging such functionality into the app domain
- Add an endpoint so different compute clusters can be discovered for different clusters, especially when distributed geographically.
- Configuration management is almost non-existent
- Need to plugin/adapt the configuration retrieval
- Puppet, Chef, or even a DKVS
- The "flavors" are hardcoded in /compute/node.py (grep for INSTANCE_TYPES)
Unknowns
- Asked jm to take a looksie into any possible Windows issues with the code base
- We know that ssh keys will not work with windows, so another method is necessary
