Open Stack

On Mon, 9 May 2016 at 19:32 Monty Taylor <mordred at inaugust.com> wrote:
[...]

> [> The point here though, is that the versions of Python that OpenStack
> > has traditionally supported have been directly tied to what the Linux
> > distributions carry in their repositories (case in point, Python 2.6
> > was dropped from most things as soon as RHEL7 was available with Python
> > 2.7). With Go, there might need to be similar restrictions.
>
> Since this is a forward-facing thing, I think starting with the version
> that's in xenial is probably fine for today, yeah? That will be the
> version of go that will get installed in the gate starting with this cycle.
>

Apologies for commenting late on this thread - I needed to catchup with the
Go maintainer in Ubuntu (CC'ed) to get things straight from an Ubuntu
perspective.

a) Distribution of Go based projects in Ubuntu

tl;dr - we've been dealing with distribution of large Go projects in Ubuntu
for a number of years - so no problem if OpenStack wants to support Go as
an official language

Ubuntu supports at least three large Go codebases in archive as of Xenial -
Juju, LXD and Snappy are all written in Go, and as a result we've had a
focus on how to support them for end-users over the last few years.

As Monty points out, Golang 1.6 is the released version of Go in Xenial
(and its also installable for Trusty - "apt-get install golang-1.6-go");
that said the way the packaging has been done, its possible to introduce
newer golang versions without breaking the existing Go based packages in
the Ubuntu archive at any point in time;   The three Canonical projects in
archive are using 1.6 as a baseline for compatibility to make things a
little easier to manage; 1.6 will remain as the default Go version, but
newer versions may be introduced in parallel.

In terms of where code for dependencies of projects sits, Ubuntu has taken
a flexible stance on this - for components where version alignment is good
and there is good reason to want to identify the versions being used across
a number of packages, a separate golang-XXX package is produced - this
allows the Ubuntu Security team to monitor for CVE's, allowing for more
effective security support. A good example of this is the go.crypto
package.  For dependencies used by a single project, or where there is not
alignment with the packaged golang-XXX version, we're continuing to use the
version embedded by the consuming project.

The Debian toolchain around Go packages helps with managing this by adding
'Built-Using' fields to all Go binary packages that depend on separate
golang-XXX packages - which means that the archive keeps track of what was
used to produce a particular binary package.  This allows the distro to
easily analyse what needs rebuilding when a shared golang-XXX package is
fixed/updated in some way, as well as letting us deal with things like
transitions between Go versions (the golang package version is also
embedded in this data).

Shared library support is coming in Ubuntu (and Debian) for Go; however we
think its something that adds value to the distributor (avoiding rebuilds
for fully statically linked binaries) rather than the developer (esp in the
context of security management).  Oh and its still really new...

b) General technical feedback on Go development in the context of OpenStack

Note that I'm not a Go developer, but have been observing Go development
across a number of large Go codebases - these are things I've seen that
help both the development team and the distributors of their work.

i) Use godeps for dependency management

This is used across Juju, LXD and Snappy to manage dependencies at specific
commits/revisions and has proved invaluable.

ii) Don't embedded your dependencies in your VCS repository

Ideally when you cut a release artefact, bundle up the dependencies at this
point in time using godeps.

iii) Agree baseline versions

For each OpenStack release agree a baseline golang version, and common
version alignment on dependencies where appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/17799c39/attachment.html>