[openstack-dev] [oslo] [placement] setting oslo config opts from environment

Doug Hellmann doug at doughellmann.com
Tue Jun 19 19:36:38 UTC 2018


Excerpts from Chris Dent's message of 2018-06-19 20:06:15 +0100:
> 
> 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
> 

I think the TripleO folks were going to look at kubernetes configmaps
for passing configuration settings into containers. I don't know how far
that research went.

I certainly have no objection to doing the work in oslo.config. As
I described on IRC today, I think we would want to implement it
using the new driver feature we're working on this cycle, even if
the driver is enabled automatically so users don't have to turn it
on. We already special case command line options and the point of
the driver interface is to give us a way to extend the lookup logic
without having to add more special cases.

This might be worth a short spec, just so we can make sure we're
covering all of the details. For example:

We will need to consider what to do with configuration settings
more complicated than primitive data types like strings and numbers.
Lists can probably be expressed with a separator character. Perhaps
more complex types like dicts are just not supported. I would like
to remove them anyway, although that doesn't seem realistic now.

We also need to work out how variable names are constructed from option
and group names.

Doug



More information about the OpenStack-dev mailing list