value interpolation

[buhman]

complete-list-of-available-variables gave me an idea.

What if we could have some interpolation syntax like:

[hubble]
OS_REGION_NAME=%(section)u

Where u is a new formatting option uppercases the value of section, where section is the name of section. section (and others) get injected into the parsers vars while building the environment.

This would result in even more concise environment declarations like:

[ord]

[buhman]

I'm aware that Env.expandVar exists, but I'd actually like to see the entire Env class go away, because this should all be implemented as native configparser extensions. Also, configparser already has interpolation, so there's no reason to NIH here; we should just add the formatter that we need.

[buhman]

It might also be more robust to use a templating engine as a configuration postprocessor. Then we can have configurations like:

[hubble]
OS_REGION_NAME={{ arbitrary_python_expression }}

This differs from preprocessing, because the value of configuration options would only be evaluated within the context of the current section/environment.

I think that's attractive, but maybe not useful enough.

[dwith]

On the topic of OS_REGION_NAME with hubble and response data being returned from cinderclient:

We now have cabinets being deployed in DFW3, which is not a problem for hubble because the networking and implementation of CBS in DFW3 is effectively just extending DFW2. What do I mean? No cbsadmin cabinets in DFW3 and No API servers there either. The new storage nodes do have FQDNs with 'dfw3' though which introduces possible ambiguity when cinderclient returns ONLY short hostnames (which I think is the only kind it returns).

I'll give an example: someone makes a cinderclient call that returns a sprawl of info with hostname and/or cinder_host fields. The casual observer of the output might not realize which hosts are actually physically in DFW3.

storage401-SATA
storage402-SATA
storage403-SATA
storage404-SATA
storage405-SATA

Looks consistent right? Wrong. storage404-SATA and storage405-SATA belong to a cab in DFW3. So, the FQDNs are actually:

storage401-SATA.dfw2.lunr.racklabs.com
storage402-SATA.dfw2.lunr.racklabs.com
storage403-SATA.dfw2.lunr.racklabs.com
storage404-SATA.dfw3.lunr.racklabs.com
storage405-SATA.dfw3.lunr.racklabs.com

I foresee problems when reporting incidents to IM and working with ESC and CIN. We want to be able to rely on cinderclient and not have to double check all of the hosts in the output just to know whether they are in dfw2 or dfw3.

I don't have the solution to this. Please dig in and help me find some way of getting FQDN from Cinder DB. Please.

[thrawn01]

This should be apart of Hubble 2.0, I've updated the milestone