Open Stack

James,

Thanks for the detailed write up straight from the trenches :)

-- Dims

On Thu, May 12, 2016 at 5:58 AM, James Page <james.page at ubuntu.com> wrote:
> 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.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims