I wasn't advocating blindly using provider APIs wherever they may exist. There should be some thought put into it to prevent some of the things you mentioned: 1. Likelihood that a long-lived bug would be allowed in the client library (very unlikely in the case of novaclient: the fact that it is used internally by the OpenStack implementation upon which many commercial providers depend, combined with the consideration that this particular client is written by the same group that writes the server, who can make sure they agree on all edge cases, etc., actually *enhances* confidence in it); and 2. Performance penalties due to fundamental mismatch (not a problem in the case of novaclient - I've looked at it and it doesn't do anything like you described - every call I implemented is one-method->one-call; heck, we could write tests to detect if it ever happens if you like).
I also don't the the async consideration is a problem. These are just socket-based clients, and these are one of the easier things to "asynchronize" with the snap of a finger with no changes to the client-code. Modern async libraries (gevent, eventlet) provide tools to patch sockets to do exactly that. Even if some nuance might possibly prevent that, though, we shouldn't be shackled by indeterminate maybes - we can do something that's better in today's reality, right now. Mike Nerone 2011/9/17 Tomaž Muraus <[email protected]> > Yeah, I must agree with Paul on this one. Libcloud started with the > assumption that we control all the code which interacts with the provider > APIs. > > If we would chose to use an existing provider library there are multiple > problems with this: > > - since we don't control the code which performs HTTP requests, adding some > kind of asynchronous API later on would be basically impossible / very > hacky > > - if there is a bug or a problem in the library which needs to be fixed > asap > we would need to wait for the original project to ship a new version first. > Other alternative is to fork the project which is bad idea. > > - There is most likely a mismatch between the provider library API and the > libcloud API. This could introduce all kind of performance penalties. For > example, because we control the code which talks to the API, this means > that > we can make some action in O(1) requests, but using the library would > result > in O(n) requests. > > Thanks, > Tomaz > > On Fri, Sep 16, 2011 at 4:47 PM, Paul Querna <[email protected]> wrote: > > > libcloud is not a collection of dependencies on other python code. it > > is a library interacting with rest APIs. > > > > this has been a core part of its design from the very beginning. > > > > -1 to merging. > > > > > > On Fri, Sep 16, 2011 at 3:18 AM, Mike Nerone > > < > reply+i-1661069-39729c8bfa0df364d880ed7936d5a186fafdb...@reply.github.com > > > > > wrote: > > > This pull request represents a new OpenStack driver based on > > python-novaclient. There are no tests at this time, so it's not ready to > > merge. I wanted to spark some discussion on this possibility, which I am > > very much for. python-novaclient is actually used internally by Rackspace > > and other OpenStack providers, so this is likely to be extremely > > well-maintained, plus novaclient already covers a lot of corner cases. To > do > > it from scratch in libcloud results in a great deal of duplication of > work > > and code, and would probably still lag on robustness unless we were to > > actually tediously crib nearly all of the novaclient logic. > > > > > > BTW, the first commit collapses the OpenStack 1.0 driver into the > > Rackspace driver (the only public implementation of OpenStack 1.0), as > has > > been discussed recently on the mailing list and in IRC, resulting in a > > general consensus that this is a good thing to do. Aside from that, the > bit > > you really want to look at for the novaclient-based driver is *all* in > > libcloud/compute/drivers/openstack.py. > > > > > > This is a proposed solution for > > https://issues.apache.org/jira/browse/LIBCLOUD-83 > > > > > > You can merge this Pull Request by running: > > > > > > git pull https://github.com/racker/libcloudnova-client-with-novaclient > > > > > > Or you can view, comment on it, or merge it online at: > > > > > > https://github.com/apache/libcloud/pull/24 > > > > > > -- Commit Summary -- > > > > > > * Remove OpenStack 1.0 support, collapsing into RS. > > > * Beginning of PoC novaclient-based Nova driver. > > > * Pyflakes, shhh. > > > * Allow a subclass to specify API version. > > > * Whoops - use the param, don't fetch the list. > > > * Add list_sizes. > > > * Add list_images. > > > * Add ex_set_password(). > > > * Add ex_set_server_name. > > > * Make _to_node handle no-IPs. > > > * Add create_node(). > > > * Add ex_resize-related methods. > > > * Use resource manager ops to save round-trips. > > > * Add rebuild(). > > > * Skeleton support for undocumented floating IPs. > > > * Add reboot_node(). > > > * Add destroy_node() and ex_get_node(). > > > * Add ex_quotas(). > > > * Add ex_save_image(). > > > * Some discussion comments. > > > * Require python-novaclient in setup.py. > > > > > > -- File Changes -- > > > > > > M libcloud/compute/drivers/openstack.py (806) > > > M libcloud/compute/drivers/rackspace.py (618) > > > M setup.py (11) > > > R test/compute/fixtures/rackspace/v1_slug_flavors_detail.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_images_detail.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_images_post.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_limits.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_servers.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_servers_detail.xml (0) > > > R > > > test/compute/fixtures/rackspace/v1_slug_servers_detail_deployment_missing.xml > > (0) > > > R > > > test/compute/fixtures/rackspace/v1_slug_servers_detail_deployment_pending.xml > > (0) > > > R > > > test/compute/fixtures/rackspace/v1_slug_servers_detail_deployment_same_uuid.xml > > (0) > > > R > > > test/compute/fixtures/rackspace/v1_slug_servers_detail_deployment_success.xml > > (0) > > > R test/compute/fixtures/rackspace/v1_slug_servers_detail_empty.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_servers_detail_metadata.xml > (0) > > > R test/compute/fixtures/rackspace/v1_slug_servers_ips.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_servers_metadata.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_shared_ip_group.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_shared_ip_groups.xml (0) > > > R test/compute/fixtures/rackspace/v1_slug_shared_ip_groups_detail.xml > (0) > > > M test/compute/test_deployment.py (2) > > > D test/compute/test_openstack.py (413) > > > M test/compute/test_rackspace.py (386) > > > > > > -- Patch Links -- > > > > > > https://github.com/apache/libcloud/pull/24.patch > > > https://github.com/apache/libcloud/pull/24.diff > > > > > > -- > > > Reply to this email directly or view it on GitHub: > > > https://github.com/apache/libcloud/pull/24 > > > > > >
