[oslo] [config] Using environment variables for config options
I don't recall seeing any specific announcement for this, and I think it is a pretty useful feature, so I thought I'd write about some functionality that I added to oslo.config and was released in 6.7.0. Especially since a lot of people I've mentioned this to thought we already had it. The new version is able to satisfy any registered config option by looking in the process environment for a variable with a predictable name and using its value if set. Options are satisfied in this order: * command line args * environment * config file(s) * everything else (using the new(ish) "sources" concept) In the past it was possible to get config from the environment if the option had been pre-defined as using something in the environment as its default. This new way is much more flexible, and in my experience ideal for container-based environments where you would like an immutable container but want small differences between multiple instances of the same container to be easy to control. Or if you don't need much config at all, you can avoid using a config file entirely. I've been using this with placement, where it's possible to set up a testable placement service with just two environment variables: OS_PLACEMENT_DATABASE__CONNECTION=mysql+pymysql://root:secret@127.0.0.1/placement?charset=utf8 OS_API__AUTH_STRATEGY=noauth2 This shows the pattern of the environment variable name: OS_<config group>__<config opt> There are some docs at https://docs.openstack.org/oslo.config/latest/reference/drivers.html#module-... I hope this proves as useful for other people as it has for me. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Chris, Have you thought on how to populate options of type ListOpt like DEFAULT/config_source? [ ]'s Moisés Em qui, 22 de nov de 2018 às 12:57, Chris Dent <cdent+os@anticdent.org> escreveu:
I don't recall seeing any specific announcement for this, and I think it is a pretty useful feature, so I thought I'd write about some functionality that I added to oslo.config and was released in 6.7.0. Especially since a lot of people I've mentioned this to thought we already had it.
The new version is able to satisfy any registered config option by looking in the process environment for a variable with a predictable name and using its value if set. Options are satisfied in this order:
* command line args * environment * config file(s) * everything else (using the new(ish) "sources" concept)
In the past it was possible to get config from the environment if the option had been pre-defined as using something in the environment as its default.
This new way is much more flexible, and in my experience ideal for container-based environments where you would like an immutable container but want small differences between multiple instances of the same container to be easy to control. Or if you don't need much config at all, you can avoid using a config file entirely.
I've been using this with placement, where it's possible to set up a testable placement service with just two environment variables:
OS_PLACEMENT_DATABASE__CONNECTION=mysql+pymysql://root:secret@127.0.0.1/placement?charset=utf8 OS_API__AUTH_STRATEGY=noauth2
This shows the pattern of the environment variable name:
OS_<config group>__<config opt>
There are some docs at https://docs.openstack.org/oslo.config/latest/reference/drivers.html#module-...
I hope this proves as useful for other people as it has for me.
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Thu, 22 Nov 2018, Moises Guimaraes de Medeiros wrote:
Have you thought on how to populate options of type ListOpt like DEFAULT/config_source?
We discussed that briefly on the spec [1] and the (temporary?) resolution there was: * Let's wait to figure that out until someone really wants to do that. The thinking being that if they want to use the complex Opt types, using environment variables for setting them may not be the right choice. * "that may just be another reason to not use those types of options" Basically, we'll cross that bridge when someone has a demand for it. My specific need was to be able to control String and Bool Opts which gets many, if not most, of the common things one might like to change _per instance_ of the service. [1] https://review.openstack.org/#/c/576860/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
participants (3)
-
Chris Dent
-
Moises Guimaraes de Medeiros
-
Thomas Goirand