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/
-----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.
- -- www.enigmail. net/
James Page
Ubuntu and Debian Developer
<email address hidden>
<email address hidden>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://
iQIcBAEBCAAGBQJ TPoyTAAoJEL/ srsug59jDC1kQAM 70KG8V8FHRcnhek OyjCtH6 g8rQ6XSqaVehlfa 4bEAZV2sj2RcVr0 vhC3TPWAEnfkmdf ZAew MFtYCB3e+ bwGH3CFQ7YWizy3 kut2JhhLvcEC7X1 SbKyQ4Wtr4 tuN3V/COy+ sg0FOnmoUYS3JBu vS2s24wCy8oSPnZ DcB+tmTuerwPLlH 0n1SRK6u61ceyfi p8OScBu4D7Nkajm z5sgT0qxPEDL4C8 rvr6 y1Ic8ylFRdvUFwg Sfv9rOHlKt3kJd5 e7lxOx4r0/ 8lYq/mge1 WMWktrqS4EVA1uX hVvYUXEigvSEJE1 J3w/wZP7DpvOZMs hcIwAsqF/ /r0 AzsV+Lrts0iiqpc K1HhJ+6C7GFbJAg 20/T29eSV+ 5m90pZ5tUSaBvOP 6mbM4FJFjKxXVeX 8nDCXGTl1V5f243 OpmnpPufUSXMFsa iWMV 8mCkQSabxTKBjtz yvSi3Q9CFMkxXc3 sDBKSITlKSVEIhO 39NK0xLz14y1 BFo2a2Ot31J6tvO f2HF5jqA0K/ yYwUCIks3/ mPeJYc0g1WwID liHte
MUBJIMLi6JIcUn6
LPvnPX3GaHuw217
EjwDE1BD/
ZYE6R4PJlYtbtq2
HV/rtTCmnyJILxs
NOVz4u/
Un3t7NZQ/
zN6q5gCNR6agMNY
6+RlXj+
ye+pttaEf78DzE9
q2XnBokObDb7Ovp
=t2vu
-----END PGP SIGNATURE-----