Open Stack

On Wed, 3 Aug 2016, Jay Pipes wrote:

> Let me know what you think about the structure of the library and whether you 
> would be interested in owning additions to the library of constants in your 
> area of expertise.

Seems mostly sane to me. I don't really care for the inspection of
sys.modules (or at least that it is inspecting the current module
rather than the one[s] where the constants actually live) but that's
a nit.

The main suggestion I would have is that you put the raw constants
(including the hierarchy) in something like YAML so that they are easy
to use without requiring Python (although most people will probably use
them that way).

It also seems a bit strange to me to have additional constant symbols to
represent data we are intending to be literally constant symbols.
But computers like that sort of stuff, so maybe that's just the way
it goes.

And then there's that naming thing. As discussed elsewhere we're
overloading "capabilities" throughout OpenStack.

> * Adding constraints functionality to the library. For instance, building in 
> information to the os-capabilities interface that would allow a set of 
> capabilities to be cross-checked for set violations. As an example, a 
> resource provider having DISK_GB inventory cannot have *both* the disk:ssd 
> *and* the disk:hdd capability strings associated with it -- clearly the disk 
> storage is either SSD or spinning disk.

That's going to be fun™.

Did you already have some ideas on how to do that? Annotate namespaces
to describe constraints on their contents? Annotate individual entries
to describe their friends or enemies?

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)         http://anticdent.org/
freenode: cdent                                         tw: @anticdent