Difference between revisions of "Nova"

Revision as of 19:52, 10 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
  • API: We need to add the Rackspace API, and a caching layer
    • It is not reasonable for us to use the Amazon API, we would be unable to innovate and would constantly be catch up
    • We would also need to add a distinct API for each service we layer on top, so they can be used with either the ec2 or racjkspace API's
• AOE
  • Definitely needs to be adapted for other services like CloudFiles, gluster, etc
• 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, we should add OVA support
• 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 (in using Windows as a host with Hyper-V? Not sure what this means)
  • We know that ssh keys will not work with windows, so another method is necessary