[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