Comment 50 for bug 1267393

Revision history for this message
James Page (james-page) wrote : Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/04/14 15:18, Matthias Klose wrote:
> - Stop bundling every source in juju-core.

I think the dh-golang helper, albeit with golang gc as the default, is
now sufficiently developed to support this for juju-core; however this
ties heavily into how jujud tools are distributed as we could end up
with a situation where the jujud built in the Ubuntu archive != jujud
built for distribution in simplestreams.

I've been thinking about this over the last few days and I can't see a
route to main for juju-core unless the jujud bits are always built
in-archive - these could still potentially be distributed via
simplestreams to support the versioned tools approach that juju takes
- - probably worth covering how this works for the benefit of others.

When a user bootstraps and environment, a tool version selection is
made based on the best compatible tools for the client version - so a
juju client at 1.17.7 would always pick from 1.17.x; the environment
sticks to this version for all new units even if there is a new 1.17.x
release - the administrator of the environment initiates an upgrade to
this new version using juju:

   juju upgrade-juju myenv

at which point the jujud daemons on the service units pickup the new
version, perform any upgrade steps and restart with the new version of
the binary. This allows the juju-core development team to have direct
control over what happens during an upgrade and how its orchestrated
across a running environment.

I think this is a unique feature which is extremely hard to address in
the packaging space and is very useful for end-users.

However this does complicate updates of any kind; thinking in the
context of a security update in a world where all juju-core
dependencies are in separate packages and juju-core is still
statically linked, the security update in the dependency requires a
rebuild of juju-core - however this must bump the version of juju-core
otherwise its not possible to effectively distribute new tools via
simplestreams.

Right now addressing an update/bug/security fix has to be done
in-conjunction with juju-core upstream (as all dependencies are
currently bundled in the source tree) so that tools and distro
binaries stay in sync (hence the need for a MRE for juju-core which I
will be submitting soon).

Patching the distro package fixes issues for those using the local
provider or using --upload-tools, but not 'normal' users consuming
tool binaries from simplestreams.

I guess if juju understood how to interrogate package versions from
the archive, it might be possible to always build a version namespaced
binary package, e.g. juju-core-1.17.8, so that the archive would
retain a history of juju-core versions, allowing juju to pick a) the
current version it needs and b) upgrade to a new version if available.

- --
James Page
Ubuntu and Debian Developer
<email address hidden>
<email address hidden>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPoyTAAoJEL/srsug59jDC1kQAM70KG8V8FHRcnhekOyjCtH6
MUBJIMLi6JIcUn6g8rQ6XSqaVehlfa4bEAZV2sj2RcVr0vhC3TPWAEnfkmdfZAew
LPvnPX3GaHuw217MFtYCB3e+bwGH3CFQ7YWizy3kut2JhhLvcEC7X1SbKyQ4Wtr4
EjwDE1BD/tuN3V/COy+sg0FOnmoUYS3JBuvS2s24wCy8oSPnZDcB+tmTuerwPLlH
ZYE6R4PJlYtbtq20n1SRK6u61ceyfip8OScBu4D7Nkajmz5sgT0qxPEDL4C8rvr6
HV/rtTCmnyJILxsy1Ic8ylFRdvUFwgSfv9rOHlKt3kJd5e7lxOx4r0/8lYq/mge1
NOVz4u/WMWktrqS4EVA1uXhVvYUXEigvSEJE1J3w/wZP7DpvOZMshcIwAsqF//r0
Un3t7NZQ/AzsV+Lrts0iiqpcK1HhJ+6C7GFbJAg20/T29eSV+5m90pZ5tUSaBvOP
zN6q5gCNR6agMNY6mbM4FJFjKxXVeX8nDCXGTl1V5f243OpmnpPufUSXMFsaiWMV
6+RlXj+8mCkQSabxTKBjtzyvSi3Q9CFMkxXc3sDBKSITlKSVEIhO39NK0xLz14y1
ye+pttaEf78DzE9BFo2a2Ot31J6tvOf2HF5jqA0K/yYwUCIks3/mPeJYc0g1WwID
q2XnBokObDb7OvpliHte
=t2vu
-----END PGP SIGNATURE-----