HW profiles vs. portal

[David Lutterkort]

Hi,

following the recent discussion[1] about HW profiles, I wanted to
outline what I think needs to happen in the dcloud API, and how portal
needs can be accomodated by all this.

Ultimately, everything we do around hardware profiles (HWP) is there to
serve one call: starting an instance in a cloud. As Bob mentioned in his
email, part of the information you submit to start an instance are
constraints on what you want for your instance[2]: 2 GB of memory, or at
least 2GB of memory; place in a specific realm or don't care what realm
etc. Eventually, we'd like to include constraints that aren't directly
connected to HWP's, like scheduling for a specific time or accomodating
EC2's new spot pricing, though that seems more like a v2 feature.

This all gets more interesting when you think about the dcloud portal,
which aggregates several clouds into one, and exposes them as one
metacloud. That has some important implications for how the dcloud API
models realms and HWP's:

* we still want people to start instances in a specific cloud, in
        addition to saying 'put it in any cloud'. That means that the
        backend clouds become realms in the metacloud, and that realms
        are hierarchical, so that the us-east-1a zone in fred's ec2
        account becomes something like the realm fred-ec2/us-east-1a
      * different realms can have different HWP's; a realm now has a
        list of HWP's associated with it
      * we still also produce a per-provider list of HWP's; for portal
        that will either be the list of all backend HWP's, or some
        reflection of pool quotas, or HWP's that an administrator
        entered in the portal admin UI (for API purposes, it doesn't
        matter, but it's nice that all these different ways of
        generating HWP can be accomodated)

In concrete terms, it seems pretty clear how to describe a HWP: each
dimension in a HWP is either a scalar range, with a unit, min and max
bounds and an optional default value, or an enumeration of opaque
strings, so that a HWP is a dictionary that maps the name of the
dimension to a scalar range or an enumeration.

When we report the HWP of a running instance, it would be nice if we
could either report back a fully resolved HWP (i.e., instance uses 2GB
of mem) or a reference to a HWP (i.e., instance uses HWP 7, which sets
memory to between 2GB and 4GB)

David

[1] https://fedorahosted.org/pipermail/deltacloud-devel/2009-November/000288.htm...
[2] to make things easier for users, we should probably express that in
    the API as 'optional base HWP + modifications to it'

[Michael Neale]

On Thu, Dec 17, 2009 at 11:54 AM, David Lutterkort  wrote:
> In concrete terms, it seems pretty clear how to describe a HWP: each
> dimension in a HWP is either a scalar range, with a unit, min and max
> bounds and an optional default value, or an enumeration of opaque
> strings, so that a HWP is a dictionary that maps the name of the
> dimension to a scalar range or an enumeration.

I think there is a case where you don't have either a range or
enumeration of opaque strings, but you might have an enumeration of
numeric/meaningful values, which a portal/client can use to decide
what to use (eg how ec2 works now, effectively). I wouldn't want it to
be either extreme only.

[David Lutterkort]

On Mon, 2009-12-21 at 11:29 +1100, Michael Neale wrote:
> On Thu, Dec 17, 2009 at 11:54 AM, David Lutterkort  wrote:
> > In concrete terms, it seems pretty clear how to describe a HWP: each
> > dimension in a HWP is either a scalar range, with a unit, min and max
> > bounds and an optional default value, or an enumeration of opaque
> > strings, so that a HWP is a dictionary that maps the name of the
> > dimension to a scalar range or an enumeration.
>
> I think there is a case where you don't have either a range or
> enumeration of opaque strings, but you might have an enumeration of
> numeric/meaningful values, which a portal/client can use to decide
> what to use (eg how ec2 works now, effectively). I wouldn't want it to
> be either extreme only.

I didn't mean that as an either .. or .., even though I used those words
- this was an inclusive or ;) As to whether the values of an enumeration
are opaque or not is slightly different, in that it doesn't affect what
a HW profile looks like; it's additional metadata about the grammar for
HW profiles (which for now might only be in some docs)

David