Open Stack

Flavio Percoco writes:

> On 11/05/16 09:47 -0500, Dean Troyer wrote:
>>On Tue, May 10, 2016 at 5:54 PM, Flavio Percoco 
>><flavio at redhat.com> wrote:
>>
>>[language mixing bits were here]
>>
>>
>>    The above is my main concern with this proposal. I've 
>>    mentioned this in the upstream review and I'm glad to have 
>>    found it here as well. The community impact of this change 
>>    is perhaps not being discussed enough and I believe, in the 
>>    long run, it'll bite us.
>>
>>
>>Agreed, but to do nothing instead is so not what we are 
>>about. The change from integrated/incubated to Big Tent was done 
>>to address some issues knowing we did not have all of the 
>>answers up front and would learn some things along the way. We 
>>did learn some things, both good and bad.
>>
>>I do believe that we can withstand the impact of a new language, 
>>particularly when we do it intentionally and knowing where some 
>>of the pitfalls are. Also, the specific request is coming from 
>>the oldest of all OpenStack projects, and one that has a history 
>>of not making big changes without _really_ good reasons. Yes it 
>>opens a door, but it will be opened with what I believe to be a 
>>really solid model to build upon in other parts of the OpenStack 
>>community.  I would MUCH rather do it this way then with a new 
>>Go-only project that is joining OpenStack from scratch in more 
>>than just the implementation language.
>
>
> So, one thing that was mentioned during the last TC meeting is 
> to decide this in a project basis. Don't open the door entirely 
> but let projects sign up for this.  This will give us a more 
> contained growth as far as projects with go-code go but it does 
> mean we'll have to do a technical analysis on every project 
> willing to sign up and it kinda goes against the principles of 
> the big tent.
>
>>
>>    The feedback from the Horizon community has been that it's 
>>    been impossible to avoid a community split and that's what 
>>    I'd like to avoid.
>>
>>
>>I do think part of this is also due to the differences in the 
>>problem domain of client/browser-side and server-side. I believe 
>>there is a similar issue with <any-language> devs writing SQL, 
>>the overlap in expertise between the two is way smaller than we 
>>all wish it was.
>
> Exactly! This separation of domains is the reason why opening 
> the door for JS code was easier. The request was for browser 
> apps that can't be written in Python.
>
>>And for the specific Python-Golang overlap, it feels to me like 
>>more Python devs have (at least talked about) working in Go than 
>>in other newish languages. There are worse choices to test the 
>>waters with.
>
> Just to stress this a bit more, I don't think the problem is the 
> language per se. There are certainly technical issues related to 
> it (packaging, CI, etc) but the main discussion is currently 
> going around the impact this change will have in the community 
> and other areas. I'm sure we can figure the technical issues 
> out.
>

One thing to consider regarding the community's ability to task 
switch is how Go is much easier than other languages and 
techniques. For example, one common tactic people suggest when 
Python becomes too slow is to rewrite the slow parts in C. In 
designate's case, rewriting the dns wire protocol aspects in C 
could be beneficial, but it would be very difficult as well. We 
would need to write an implementation that is able to safely parse 
dns wire format in a reasonably thread safe fashion that also will 
work well when those threads have been patched by eventlet, all 
while writing C code that is compatible with Python internals.

To contrast that, the go POC was able to use a well tested go DNS 
library and implement the same documented interface that was then 
testable via the same functional tests. It also allowed an 
extremely simple deployment and had a minimal impact for our CI 
systems. Finally, as other go code has been written on our small 
team, getting Python developers up to speed has been 
trivial. Memory management, built in concurrency primitives, and 
similar language constructs have made using Go feel natural.

This experience is different from JavaScript because there are 
very specific silos between the UI and the backend. I'd expect 
that, even though JavaScript is an accepted language in OpenStack, 
writing a node.js service would prevent a whole host of new 
complexity the project would similarly debate. Fortunately, on a 
technical level, I believe we can try Go without its requirements 
putting a large burden on the CI team resources.

Eric

> Flavio
>
>>dt
>>
>>--
>>
>>Dean Troyer dtroyer at gmail.com


--

Eric Larson         | eric.larson at rackspace.com Software Developer 
| Cloud DNS | OpenStack Designate Rackspace Hosting   | Austin, 
Texas