The image problem is difficult, I see. My thought would be just to mark images as None if it's not possible to detect from a provider field. My workflow generally consists of sticking to ubuntu 10.04 for the base image, and I don't mind sorting out the official image/architecture on a per-provider basis. I just want to make sure I can get a consistent node kernel, for apt-get (sudo aptitude install ia32-libs).
Node/kernel sizes should be able to be determined without a huge amount of effort... AFAIK most providers offer 64 bit kernels by default, and then offer 32-bit userland by default (brightbox, for example). Amazon is a bit weird in that sense since they offer 32-bit kernels. Anybody know of anyone else offering 32-bit? The key point is that 64-bit kernels should be able to load anything (64-bit, 32-bit, or None/unknown), whereas 32-bit kernels would need an explicit 32 bit image. If you can just nail down the node size architecture, it's still useful. Another thought re: specifying node sizes... Many other providers have a granular ability to specify memory, cpu "size", and disk size independently. My thought would be, rather than retrieving a consistent global list of generic nodes, there should be some ability to query for matching nodes per-provider. E.g. instead of the list_nodes() function, a function such as: query_sizes(min_cpu, min_disk, max_price, etc...) could be specified. For providers that have static node sizes, the global list is filtered based on the parameters provided. For providers that have granular specification, a list containing a single node is returned. The single node is tuned to the query requirements as closely as possible. Thanks again to the libcloud team, I really appreciate the organizational efforts behind this project -Justin On Mon, Apr 18, 2011 at 3:20 AM, Tomaz Muraus <[email protected]> wrote: > In general I am OK with adding "architecture" attribute to the NodeSize and > NodeImage class. > > Before adding it, we would need to research how many providers actually > expose this attributes through their API. > > I know that many providers don't explicitly include architecture attribute > in the "list images" response so to figure out the actual image architecture > we would need to parse it from the image name which is less than ideal. > > > > -- Justin Donaldson, BigML, Inc. o: 313-31BIGML | c: 919-BUZZJJD
