Open Stack

Dugger, Donald D said on Mon, Aug 03, 2015 at 05:39:49AM +0000:
> Also note that, although many capabilities can be represented by
> simple key/value pairs (e.g. the presence of a specific special
> instruction) that is not true for all capabilities (e.g. Numa topology
> doesn't really fit into this model) and even the need to specify
> ranges of values (more that x byes of RAM, less than y bandwidth
> utilization) makes things more complex.

I'm glad you brought up ranges. I don't want to get too exotic
prematurely but these certainly seem useful.

> Without going into the solution space the first thing we need to do is
> make sure we know what the requirements are for exposing host
> capabilities.  At a minimum we need to:
> 
> 1)      Enumerate the capabilities.  This will involve both
> quantitative values (amount of RAM, amount of disk, ...) and Boolean
> (magic instructions present).  Also, there will be static capabilities
> that are discovered at boot time and don't change afterwards and
> dynamic capabilities that vary during node operation.
> 
> 2)      Expose the capabilities to both users and operators.

As discussed at the midcycle, part of this is presenting a
somewhat-uniform API. I was fairly sleepy but I seem to recall PowerVM
does not publish an exhaustive list of its capabilities? Do we need a
facade which lists implicit capabilities for newer CPUs?

We might also want to abstract over similar capabilities in Intel and
PowerVM?

> 3)      Request specific capabilities.  A way of requesting an
> instance with an explicit list of specific capabilities is a minimal
> requirement.  It would probably also be good to have a way to easily
> specify an aggregate that encompasses a set of capabilities.
> 
> Note that I'm not saying we should remove flavors, but we might need a
> different way to specify what makes up a flavor.

We seemed to like an "ISP model" - where you get your core functionality
flavor (vcpus, RAM, disk etc) then whatever addon flavors you want (SSD,
extra volumes etc), with the option to individually specify whichever
requirements your cloud provider allows. One can imagine most clouds
disabling the lattermost and offering more or less addons depending on
how much space they're willing to write off to fragmentation.

>From a scheduler point of view, I'd like flavors to become an API thing.
IE a way for the deployer to constrain their users. Internally I don't
see why we should deal with anything other than pools of resources,
with requests and claims against them.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.