You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Paul Querna <pa...@querna.org> on 2009/12/31 08:44:46 UTC

[libcloud] expanding & rethinking create_node

Hi,

I've been running in to too much pain by the already diverging use of
kwargs to expose what we have been caling "provider specific
features".

I think however, we are taking the wrong approach.

In trunk now, create_node takes 3 parameters:
   name, options, **kwargs
Previously it took:
  name, image, size

The NodeOptions object however, adds both:
  - Server Physical location, aka Data Center
  - Initial Server Authentication (SSH Key or Password).

So far I've just updated the Linode driver to use this syntax, mostly
by removing several of its kwargs.

Personally, I want to squash and make portable as much of the kwarg
usage as possible.  I believe we have a mandate that if >1.2 providers
do something, we should make it generic, and avoid exposing kwargs
except when a provider is doing something truly unique or
experimental.

The addition of location is a pretty obvious issue with the existing
API -- treating amazon US/EU specially was different enough, and we
are seeing other providers support multiple datacenters -- I think we
need to embrace multiple locations and go with it.

The one major issue not solved yet is the ability of list sizes and
list images to be location sensitive.  I think this could be as simple
as passing an optional NodeLocation object to list_{images,sizes} etc.

For Server Authentication, I've just scratched the surface by exposing
an SSH Key or Password option -- for quite a few providers this will
work, but for others there is no way to put files on the server,
unless they are part of the image.  I think this part of the API
really needs some serious thought.

In order to still allow providers to have differentiated features, but
still allow end users to avoid having if provider == "foo" checks all
over,  I've added a driver.has_feature() API.

Example usage for authentication:

auth = None
if driver.has_feature(Features.AUTH_SSH_KEY):
   auth = NodeAuthSSHKey(open("mykey.pub").read())
elif driver.has_feature(Features.AUTH_PASSWORD):
  auth = NodeAuthPassword(mypass)

driver.create_node("new-machine", NodeOptions(size=size, image=image,
location=location, auth=auth))

Thoughts on these API changes?

Thanks,

Paul

Re: [libcloud] expanding & rethinking create_node

Posted by Ian Bicking <ia...@gmail.com>.
On Thu, Dec 31, 2009 at 1:44 AM, Paul Querna <pa...@querna.org> wrote:

> Example usage for authentication:
>
> auth = None
> if driver.has_feature(Features.AUTH_SSH_KEY):
>   auth = NodeAuthSSHKey(open("mykey.pub").read())
> elif driver.has_feature(Features.AUTH_PASSWORD):
>  auth = NodeAuthPassword(mypass)
>
> driver.create_node("new-machine", NodeOptions(size=size, image=image,
> location=location, auth=auth))
>
> Thoughts on these API changes?


Maybe this could be done in a lighter manner.  For instance:

if 'ssh_key' in driver.create_node.features:
    kw = dict(ssh_key=open('mykey.pub').read())
elif 'password' in driver.create_node.features:
    kw = dict(password=mypass) # username?
else:
    assert False, "How do you auth then?!?"

driver.create_node('new-machine', **kw)


Documentation should cover the possible keyword arguments, and of course
drivers for services that provide the same features should use the same
keyword.

This way the API isn't really any more complicated than it is now, and if
you aren't being particularly provider-agnostic then you don't have to worry
about this stuff, but if you are provider agnostic then there's the metadata
to support that.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker