Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of paul@querna.org designates
 209.85.211.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1263217273.3439.227.camel@urgyen>
References: <1263217273.3439.227.camel@urgyen>
Date: Thu, 14 Jan 2010 12:56:24 -0800
Message-ID: <4239a4321001141256l2985bc39o138d4bc191c8c6d6@mail.gmail.com>
From: Paul Querna <paul@querna.org>
To: libcloud@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [libcloud] Voxel support - how to handle sizes and creates

On Mon, Jan 11, 2010 at 5:41 AM, Upayavira <uv@odoko.co.uk> wrote:
> I've mostly implemented support for Voxel in libcloud.
>
> I've done everything but create_node and list_sizes, as I haven't yet
> worked out how best to implement them.
>
> My main question is that libcloud expects discrete "sizes", whereas at
> Voxel the memory/CPU are not tied to the disk usage. A 10 core device
> could have a 10Gb disk while a 1 core device could have a 1Tb disk.

Yup, several providers allow this kind of variable NodeSize.

I think the best thing we can do is in two parts:
1) Add a features["list_sizes"] dict, with:
  - variable_disk
  - variable_cores
  - variable_memory

If these features attributes are set, its an indicator to a user of
the driver, they are safe to set arbitrary values on the NodeSize
object.

2) We should make a sensible set of default NodeSizes, this is what
the vcloud driver does for example with regards to memory.  I would
suggest just making a set of NodeSizes that is roughly the same as
what amazon or rackspace offer.

This keeps the library easy to use for people who just want a node
quickly, but also provides an API defined way for variable NodeSize
objects.

Thoughts?

Thanks,

Paul