Open Stack

On Mon, Nov 7, 2016 at 3:53 PM, Joshua Harlow <harlowja at fastmail.com> wrote:

>
>> Concretely - oslo.config is important because it shapes what the config
>> files look like. The implementation language of a particular service
>> shouldn't change what our config files look like, yeah?
>>
>
> 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).
>
> 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).
>
> 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).
>
>
>> Similarly keystoneauth - not because getting a token from keystone with
>> a username and password is necessarily hard- but because we're trying to
>> drive more service-service interactions through the catalog to reduce
>> the number of things an operator needs to configure directly - and also
>> because keystone has auth plugins that need to be supported in the new
>> language too. (it's a common fault in non-python client implementations
>> that non-password auth plugins are not covered at all)
>>
>> oslo.log has similar needs - the logging for an operator needs to be
>> able to be routed to the same places and be in the same format as the
>> existing things.
>>
>
> 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).
>
>
>> oslo.messaging and oslo.db have needs where they intersect with operator
>> config.
>>
>
> 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).
>
> -Josh
>
>
>
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.

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).

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.

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).

My $0.002.

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161107/a7b5f2fb/attachment.html>