Today's objectives

• Get feedback about Libcloud usage and weaknesses
• Brainstorm possible solutions
• Try to agree on a solution and prioritize implementation

Agenda

• Current state of the art
• Current weak / pain points
• Addressing current pain points

Whole thing is interactive so please provide your feedback in real time!

Current state of the art (code)

• Four primary APIs - compute, storage, loadbalancer, dns
• A lot of drivers
• Support for multiple Python versions (2.5 to 3.3)
• Good abstraction around async APIs
• Good pagination abstraction
• Healthy number of releases

Current state of the art - releases

Current state of the art (community)

• Healthy and steady number of external contributions and contributors
• We could do better with committer contributions
• Some providers have a "go to person" for their Libcloud driver

Current state of the art - contributors

Current weak / pain points

• Using providers with multiple regions
• Provider capability discovery
• Exception handling in methods which perform multiple API calls
• Documentation

Using providers with multiple regions

Currently

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

Cls1 = get_driver(Provider.RACKSPACE_NOVA_LON)
Cls2 = get_driver(Provider.RACKSPACE_NOVA_DFW)

driver1 = Cls1('username', 'api key')
driver2 = Cls2('username', 'api key')

• One driver per region
• Hard to manage, not user friendly
• Need to release a new version if provider adds a region*

* In some cases impossible to avoid even with new approach

Using providers with multiple regions

In trunk

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

Cls = get_driver(Provider.RACKSPACE)

driver1 = Cls('username', 'api key', datacenter='lon')
driver2 = Cls('username', 'api key', datacenter='dfw')

• Big Improvement over current approach
• Backward incompatible
• Not fully finished yet

Provider capability discovery

• Not straightforward to detect which methods each provider supports
• We have docstrings, but that's messy
• Maybe use zope.interface (again)?
• ABC?
• Suggestions welcome

Exception handling in methods which perform multiple API calls

• Simple example - create_node in EC2 compute driver:
  • 1. Create a node
  • 2. Create a tag 'name' for the created node
• What happens if #2 fails?
• Currently it's non-fatal / we just ignore it
• Should propagate exception to the user and provide a way to rollback / get back to the consistent state

Documentation

• Big weak point
• It's in SVN, everyone can and is welcome to contribute
• Should do a "documentation sprint"

Misc

• Dropping Python 2.5 support
• Pricing data distribution
• Test improvements
• Async support in the core
• Move to Git - decrease barrier to entry

Thank you

• Website: http://libcloud.apache.org
• Docs: http://libcloud.apache.org/docs/
• Mailing lists: {users,dev}@libcloud.apache.org
• IRC: #libcloud on irc.freenode.net