Open Stack

Every now and again I keep working on my experiments to containerize
placement in a useful way [1]. At the moment I have it down to using
a very small oslo_config-style conf file. I'd like to take it the
rest of the way and have no file at all so that my container can be
an immutable black box that's presence on the network and use of a
database is all external to itself and I can add and remove them at
will with very little effort and no mounts or file copies.

This is the way placement has been designed from the start. Internal
to itself all it really knows is what database it wants to talk to,
and how to talk to keystone for auth. That's what's in the conf
file. We recently added support for policy, but it is policy-in-code
and the defaults are okay, so no policy file required. Placement
cannot create fully qualified URLs within itself. This is good and
correct: it doesn't need to.

With that preamble out of the way, what I'd like to be able to do is
make it so the placement service can start up and get its necessary
configuration information from environment variables (which docker
or k8s or whatever other orchestration you're using would set).
There are plenty of ways to hack this into the existing code, but I
would prefer to do it in a way that is useful and reusable by other
people who want to do the same thing.

So I'd like people's feedback and ideas on what they think of the
following ways, and any other ideas they have. Or if oslo_config
already does this and I just missed it, please set me straight.

1) I initially thought that the simplest way to do this would be to
set a default when describing the options to do something like
`default=os.environ.get('something', the_original_default)` but this
has a bit of a flaw. It means that the conf.file wins over the
environment and this is backwards from the expected [2] priority.

2) When the service starts up, after it reads its own config, but
before it actually does anything, it inspects the environment for
a suite of variables which it uses to clobber the settings that came
from files with the values in the environment.

3) 2, but it happens in oslo_config instead of the service's own
code, perhaps with a `from_env` kwarg when defining the opts. Maybe
just for StrOpt, and maybe with some kind of automated env-naming
scheme.

4) Something else? What do you think?

Note that the main goal here is to avoid files, so solutions that
are "read the environment variables to then write a custom config
file" are not in this domain (although surely useful in other
domains).

We had some IRC discussion about this [3] if you want a bit more
context. Thanks for your interest and attention.

[1] https://anticdent.org/placement-container-playground-6.html
[2] https://bugs.launchpad.net/oslo-incubator/+bug/1196368
[3] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-06-19.log.html#t2018-06-19T18:30:12


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent