<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 3:53 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Concretely - oslo.config is important because it shapes what the config<br>
files look like. The implementation language of a particular service<br>
shouldn't change what our config files look like, yeah?<br>
</blockquote>
<br></span>
Standards though exist for a reason (and ini files are pretty common across languages and such); though of course oslo.config has some very tight integration with openstack, the underlying ini concept it eventually reads/writes really isn't that special (so hopefully such a thing existing isn't that hard).<br>
<br>
As a note gflags in go (which I think is the default option mechanism?) is alot like oslo.config (in fact oslo.config came from a python version of gflags way back when).<br>
<br>
Personally though I'd prefer to just say (if I could) 'ini' file is the standard format for options in openstack (and drop the mix of command line options and configuration/ini file options).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Similarly keystoneauth - not because getting a token from keystone with<br>
a username and password is necessarily hard- but because we're trying to<br>
drive more service-service interactions through the catalog to reduce<br>
the number of things an operator needs to configure directly - and also<br>
because keystone has auth plugins that need to be supported in the new<br>
language too. (it's a common fault in non-python client implementations<br>
that non-password auth plugins are not covered at all)<br>
<br>
oslo.log has similar needs - the logging for an operator needs to be<br>
able to be routed to the same places and be in the same format as the<br>
existing things.<br>
</blockquote>
<br></span>
Pretty sure most systems have logging that is similar to java logging (which afaik is where the python logging system came from/was inspired from); oslo.log has some specific tie-ins to oslo.config (but see above statement of using a ini file as the option mechanism).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
oslo.messaging and oslo.db have needs where they intersect with operator<br>
config.<br>
</blockquote>
<br></span>
I hope we aren't restricting ourselves to much because of the specialized libraries we have made that typically have (some level) of equivalent in other languages. Though of course those languages and libraries do not typically(?) have the tie-together that we have created with our libraries (for better or worse).<br>
<br>
-Josh<div class="HOEnZb"><div class="h5"><br>
<br></div></div></blockquote><div><br></div><div>The config file format, Logging (as long as we can get similar formatted logging), and KeystoneAuth are the really important ones. Oslo.db, oslo.messaging may not be needed directly in <new language here>, they may need to be, we will need to see what bits are natively available. I am going to guess most modern languages will have INI-style config parsing, ORM-like support, and the ability to format logging.</div><div><br></div><div>Keep in mind that oslo.db, oslo.messaging, oslo.log are largely convenience wrappers that may not be mirrored (much) in another language due to solid first-class support (either via library or native in the language).</div><div><br></div><div>When it comes to KeystoneAuth, I would be interested if there is solid technology that would let us (similar to how protobuf works), prototype/build the logic and then compile the bindings/library for multiple languages. My biggest concern is touched on by Monty, if we have something that needs to interact with other services it should utilize the logic we have built in KeystoneAuth. It would be remiss if we had <new language> keystoneauth that was not maintained at the same level as the main keystone auth. KeystoneAuth has a bunch of business logic in it.</div><div><br></div><div>Similar to KeystoneAuth, the KeystoneMiddleware has a number of pitfalls when validating a token for consumption. If this is not in Python, we should be working hard to ensure we have consistent validation (possibly a longer-term-goal) in any language that is "officially supported". Most of the time when folks implement their own token validation, it ends up running into edge cases (just because middleware is very actively watched / fixed when these edge cases occur).</div><div><br></div><div>My $0.002.</div><div><br></div><div>--Morgan</div><div><br></div><div><br></div></div></div></div>