Using Openstack scheduler hints with juju

[William Reade]

On Fri, 2013-02-01 at 00:37 +0000, Martin Packman wrote:
> A list of string uuids can also be given rather than a single string
> uuid. Spaces are accepted by the json parser, but are a little tricky
> to handle in constraint specification so are carefully omitted in
> these examples.

Requiring that the user worry about actual instance ids is bad juju ;).
Would you describe the use cases that originally prompted this work? If
they're similar to the following:

  * Units of service X should be deployed to instances running on
    different physical machines ("I want my mongos to be separated").
  * Units of service X should be deployed to instances that are
    running on the same physical machine as some unit of service Y
    ("I want rabbitmq near mysql").

...then it might be that it can be usefully expressed as an assignment
policy. The assignment policy has hitherto been underused, but is
becoming directly relevant in the context of colocation; the short
version is that an assignment policy is analogous to a constraint, but
(1) is applied at a unit resolution and (2) can take state into account
when determining what to do. Does this sound helpful to you?

> There are several configuration options that are involved on the
> openstack deployment side, if any are set incorrectly nova will
> happily schedule you a server anyway, but without understanding or
> acting on any hints given.
...
> Getting that that configuration value changed is the last wrinkle that
> we're stuck on for now. We deploy Openstack itself using juju, and the
> charms[nova-compute] used have a neat option
> 'config-flags'[config-flags] that should allow (live?) nova.conf
> updating.
> 
> However, it's defined as a 'string' when it's really a dict of comma
> separated key-pairs. As the config value we need to change also
> contains commas, and both the charm[shell-parsing] and nova are naive
> about parsing. Is there any reason we can't make this option a yaml
> dict and teach the charm how to interpret that?

My understanding is that charm configuration was restricted to the few
available types on the basis that this technique shouldn't be necessary:
a charm should be sufficiently opinionated to know the Right Way to
deploy a service with a particular goal in mind, and should prefer to
expose configuration options at a high level [0]. For example, in this
case, something like "scheduler-driver=chance|filter"? [1]

Cheers
William


[0] for example, "tuning" in
http://jujucharms.com/charms/precise/wordpress

[1] I'm sure I've oversimplified the problem; but is there complexity
that needs to be exposed to the charm's user at this stage? If there is,
I'd like to hear about it so we can figure out the right path in the
face of real usage.