Open Stack

On 11/07/2016 11:58 AM, Hayes, Graham wrote:
> On 07/11/2016 17:14, Flavio Percoco wrote:
>> Greetings,
>>
>> I literally just posted a thing on my blog with some thoughts of what I'd expect
>> any new language being proposed for OpenStack to cover before it can be
>> accepted.
>>
>> The goal is to set the expectations right for what's needed for new languages to
>> be accepted in the community. During the last evaluation of the Go proposal I
>> raised some concerns but I also said I was not closed to discussing this again
>> in the future. It's clear we've not documented expectations yet and this is a
>> first step to get that going before a new proposal comes up and we start
>> discussing this topic again.
>>
>> I don't think a blog post is the "way we should do this" but it was my way to
>> dump what's in my brain before working on something official (which I'll do
>> this/next week).
>>
>> I also don't think this list is perfect. It could either be too restrictive or
>> too open but it's a first step. I won't paste the content of my post in this
>> email but I'll provide a tl;dr and eventually come back with the actual
>> reference document patch. I thought I'd drop this here in case people read my
>> post and were confused about what's going on there.
>>
>> Ok, here's the TL;DR of what I believe we should know/do before accepting a new
>> language into the community:
> 
> Its a great starting point, but there is one issue:
> 
> This is a *huge* amount of work to get into place, for the TC to still
> potentially refuse the language. (I know you covered this in your blog
> post, but I think there is a level of underestimation there.)

Yes, it is absolutely a huge amount of work for sure, and I think your
point is important.

> 
>> - Define a way to share code/libraries for projects using the language
> 
> ++ - Definitely needed
> 
>> - Work on a basic set of libraries for OpenStack base services
> 
> What do we include here? You called out these:
> 
> keystoneauth / keystone-client
> oslo.config
> oslo.db
> oslo.messaging
> 
> We need to also include
> 
> oslo.log
> 
> Do they *all* need to be implemented? Just some? Do they need feature
> parity?

To me the most important piece is feature parity on the operator
interaction side.

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?

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.

oslo.messaging and oslo.db have needs where they intersect with operator
config.

> For example the previous discussion about Go had 2 components that would
> have required at most 2 of these base libraries (and I think that was
> mainly on the Designate side - the swift implementation did not need
> any (I think - I am open to correction)
> 
>> - Define how the deliverables are distributed
> 
> ++ - but this needs to be done with the release management teams input.
> What I think is reasonable may not be something that they are interested
> in supporting.
> 
>> - Define how stable maintenance will work
> 
> ++
> 
>> - Setup the CI pipelines for the new language
> 
> This requires the -infra team dedicate (what are already stretched)
> resources to a theoretical situation, doing work that may be thrown
> away if the TC rejects a language.
> 
> I foresee these requirements as a whole being overly onerous, and
> having the same result as saying "no new languages".
> 
> I think that there should be base research into all of these, but the
> requirements for some of these to be fully completed could be basically
> impossible.

Having a solution for deliverable distribution, stable maintenance,
shared requirements management and caching/mirroring for the gate are
things I personally think are pre-requisites. They're conceptually hard
but not necessarily a giant amount of hands-on-ground work. (some work,
but not an excessive amount) They represent the parts of the
intra-developer social contract that exists within the structures of how
we operate on repositories.

I would think that library coverage needs a plan, but doesn't need to be
_finished_ - until such a time as the deliverable in question needs to
be delivered. Or, put another way - we need to have a clear list of
things and a mechanism for doing them - but we don't need a logging
library until we have a thing that needs to log. That said, the instant
we have a thing in the new language that needs to log, it needs to be
understood that it needs to be done in a logging-library manner and that
the design needs to be strongly tied to the existing operator interface
for existing OpenStack components.

I agree that actually writing duplicates of all the oslo libraries
before doing any coding is way too high of a barrier.

On the other hand, before patches can land, someone needs to know how
zuul is going to properly clone the git repos associated with the
project, or else the code in question will not be properly tested and
we'll be in a painful position, no?

Monty