incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <>
Subject Re: [libcloud] 0.3.x goals
Date Fri, 19 Feb 2010 19:22:23 GMT
On Thu, Feb 18, 2010 at 3:36 AM, Upayavira <> wrote:
> This is all the exact use-case I had for libcloud.

Me too. I like Solomon's idea of providing a runurl service on boot.
This is easy to do with EC2 as a user data script
( Rackspace too,
with its file injection facility at create time.

As Paul notes, there are a few obstacles to doing this on all
providers. For example, on Terremark you would have to scp a script
(using a known password), then run it (using ssh, again using the
known password). The script would probably disable the default account
as the first thing it did.

I imagine this would be an optional feature. If it couldn't be
implemented for a provider, it would be a no op.

Another feature I would like to see is the ability to assign roles
(groups) to instances. You can then perform operations for all
instances in a particular role in one go - e.g. terminate all
instances in a given role. This wouldn't necessarily be a core feature
- it could be an extension module or something. I do this today using
security groups in EC2, metadata in Rackspace, and instance-name
encoding in Terremark. I find it useful for an instance to know which
roles it is in too (so it can configure itself appropriately) so this
would probably tie into the boot time information.


> Ideally I could use it to fire up a VM, and tell the host how to
> configure itself. I have had such code working against ec2, and now
> working against Voxel. I've considered Puppet, but one issue is that it
> doesn't handle instance creation. Combine Puppet with something like
> libcloud and you end up with a powerful combination.
> Note, for the Voxel API you can provide a script as a parameter at
> creation time. That script will be executed on the VM once it has been
> instantiated.
> Upayavira
> On Thu, 2010-02-11 at 08:51 -0800, Paul Querna wrote:
>> On Thu, Feb 11, 2010 at 2:38 AM, Solomon Hykes <> wrote:
>> > On Thu, Feb 11, 2010 at 3:18 AM, Paul Querna <> wrote:
>> >
>> >> I think an interesting API to provide is the minimum needed to
>> >> kickstart any of the above deployment systems.
>> >
>> > I agree entirely. The less abstraction we can get away with, the better.
>> >
>> >> For example, if we provided a deploy_node() api, which takes a similar
>> >> kwargs to create_node [...]
>> >
>> > Why not simply add kwargs to create_node? See below.
>> >
>> >> after the node is booted, SSHes in,
>> >> installs a few specific things, copies a small number of files into
>> >> the machine, and starts a service.  The actual actions could be a
>> >> class for each of the above configuration management systems, with the
>> >> ability to add your own.
>> >
>> > I like the process. It seems to me the only abstraction we need here
>> > is the ability to run commands on the node, with a "runurl" ability to
>> > pull commands from a remote url.
>> >
>> > The result would look like this:
>> > create_node(runurl="http://somewhere.tld/")
>> Well, not quite, there are a few barriers:
>>  - You need to authenticate into the host.  Depending on the provider,
>> this is either done by providing a password, an ssh key, or receiving
>> a password after booting, or as Ian mentioned, via an existing ssh
>> key.
>>  - You would need to install runurl, this most likely means either
>> just SCPing it up, but you'll still want to use apt or yum or X to
>> install curl or wget etc.

View raw message