incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <tom.e.wh...@gmail.com>
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 <uv@odoko.co.uk> 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
(http://alestic.com/2009/06/ec2-user-data-scripts). 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.

Cheers,
Tom



>
> 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 <solomon.hykes@gmail.com> wrote:
>> > On Thu, Feb 11, 2010 at 3:18 AM, Paul Querna <paul@querna.org> 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/webserver-bootstrap.sh")
>>
>> 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.
>
>
>

Mime
View raw message