Open Stack

Excerpts from Fox, Kevin M's message of 2016-05-03 22:11:06 +0000:
> If we let go in, and there are no pluggable middleware, where does RadosGW and other Swift api compatible implementations then stand? Should we bless c++ too? As I understand it, there are a lot of clouds deployed with the RadosGW but Refstack rejects them.

RadosGW isn't part of an OpenStack project, and DefCore requires running
the code produced by our community, not just code that meets the same
APIs.

Doug

> 
> Thanks,
> Kevin 
> ________________________________________
> From: Doug Hellmann [doug at doughellmann.com]
> Sent: Tuesday, May 03, 2016 2:50 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc] supporting Go
> 
> Excerpts from John Dickinson's message of 2016-05-03 13:01:28 -0700:
> >
> > On 3 May 2016, at 12:19, Monty Taylor wrote:
> >
> > > On 05/03/2016 01:45 PM, Michael Krotscheck wrote:
> > >> On Tue, May 3, 2016 at 9:03 AM John Dickinson <me at not.mn
> > >> <mailto:me at not.mn>> wrote:
> > >>
> > >>
> > >>     As a starting point, what would you like to see addressed in the
> > >>     document I'm drafting?
> > >>
> > >>
> > >> I'm going through this project with JavaScript right now. Here's some of
> > >> the things I've had to address:
> > >>
> > >> - Common language formatting rules (ensure that a pep8-like thing exists).
> > >> - Mirroring dependencies?
> > >> - Building Documentation
> > >
> > > Mirroring and building are the ones that we'll definitely want to work together on in terms of figuring out how to support. go get being able to point at any git repo for depends is neat - but it increases the amount of internet surface-area in the gate. Last time I looked (last year) there were options for doing just the fetch part of go get separate from the build part.
> > >
> > > In any case, as much info as you can get about the mechanics of downloading dependencies, especially as it relates to pre-caching or pointing build systems at local mirrors of things holistically rather than by modifying the source code would be useful. We've gone through a couple of design iterations on javascript support as we've dived in further.
> >
> > Are these the sort of things that need to be in a resolution saying that it's ok to write code in Golang? I'll definitely agree that these questions are important, and I don't have the answers yet (although I expect we will by the time any Golang code lands in Swift). We've already got the Consistent Testing Interface doc[1] which talks about having tests, a coding style, and docs (amongst other things). Does a resolution about Golang being acceptable need to describe dependency management, build tooling, and CI?
> 
> There are separate interfaces described there for Python and JavaScript.
> I think it makes sense to start documenting the expected interface for
> projects written in Go, for the same reason that we have the others, and
> I don't think we would want to say "Go is fine" until we at least have a
> start on that documentation -- otherwise we have a gap where projects
> may do whatever they want, and we have to work to get them back into
> sync.
> 
> Doug
> 
> >
> > --John
> >
> >
> >
> >
> > [1] http://governance.openstack.org/reference/project-testing-interface.html
>