[openstack-dev] Golang technical requirements

Monty Taylor mordred at inaugust.com
Tue Dec 13 20:17:21 UTC 2016


On 12/13/2016 12:45 PM, Dean Troyer wrote:
> I am working on scoping the tasks required for the technical pieces of
> Golang adoption in OpenStack.  This work has been informed somewhat by
> flaper87's reference doc proposal[0] for new language additions and is
> (mostly) compatible with it, pending that proposal's final approval by
> the TC.
> 
> As a first step, I proposed a Common Testing Interface (CTI)
> document[1] for Go.  There is, of course, much more than this,
> including a number of significant decisions that still need to be
> made.  At this point I want to focus on identifying those decisions
> and other tasks rather than solving them immediately.
> 
> Some of the previous work done around using Golang in OpenStack has
> been collected in an Etherpad[2] and summarized into major categories.
> I am confident that I have not found everything that has been done and
> would appreciate pointers to whatever resources you may have.  Here
> are some highlights of areas that still require discussion and
> decisions:
> 
> 
> Common Libraries
> 
> flaper87's reference doc touches on project requirements for new
> languages and Oslo-compatible implementations.  At the time of this
> writing this is not yet finalized, with some discussion around how
> much to require, and if the first project to utilize a new language
> should shoulder all of the burden of also implementing those
> libraries.
> 
> 
> Dependency Management
> 
> There are a number of tools available for Golang to manage
> dependencies.  A number have been evaluated already with a couple of
> strong contenders identified.  Once a tool is selected, process needs
> to be set up to track dependencies and versions tested.

Figuring out how to get from that to pre-cached git repos in gate nodes
is another important task. Actually cloning from github during CI jobs
leads to wailing and gnashing of teeth pretty quickly. That said - godep
and glide both lend themselves well towards doing such a thing.

We also need to rework how zuul clones git repos a little bit so that
intra-OpenStack cross-repo dependencies work properly. In short, we
should have zuul clone to $BASE/src/git.openstack.org/openstack/nova
instead of $BASE/openstack/nova so that we can just point $GOPATH at
$BASE and have things just work. That obviously involves a change to
zuul to do the cloning, and to devstack to start grokking another level
of source repo organization. On the plus-side though, I think it'll be
nicer even for non-go related things, so is well worth doing.

Finally- (and this one is easy) - we need to put a pointer files at the
root of git.o.o and review.o.o to mark git.o.o/${repo}.git as the
canonical location of repositories.

https://golang.org/cmd/go/#hdr-Relative_import_paths

has instructions on this.

> Release Deliverables
> 
> OpenStack still officially considers the tarballs generated during the
> release rpocess to be our official deliverable.  Many downstream
> consumers, however, bypass those and go directly to the tagged
> releases in the Git repos.  The Golang community has no real culture
> of using tarballs at all, given the 'go get' functionality bult in to
> the tooling directly for checking out remote repos.  One obvious
> shortcoming in just defining the release to be Git repo tags is our
> use of generated files.

Indeed. On the other hand - our use of git tags to drive our
deliverables (and pbr's use of them instead of content in a file in the
source repo) actually has us more closely aligned with this than other
projects might be.

> 
> If you have an interest in seeing Golang support implemented for
> OpenStack, please jump in here and help us nail down how to accomplish
> that "right".
> 
> dt
> 
> [0] https://review.openstack.org/#/c/398875/
> [1] https://review.openstack.org/410355
> [2] https://etherpad.openstack.org/p/golang-infra-work-plan
> 




More information about the OpenStack-dev mailing list