juju-core 1.22.1 is not packaged in Ubuntu

Bug #1444037 reported by Oleg Strikov on 2015-04-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-core (Ubuntu)

Bug Description

We're now in a position to have 1.22.1 enter trusty-proposed and vivid-proposed, but it should not land in trusty or vivid until upstream passes QA on our proposed binaries, published the tools in their stable simplestream and announces the release for general production use.

[SRU Information]

juju-core has a stable release exception in https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions, including for major version updates.

[Development Fix]

Upload of new upstream release with packaging review. [strikov] will remove the block-proposed tag when verification has passed, and then this update should migrate to vivid.

[Stable Fix]

Full backport of new upstream release.

[Pre-QA tasks]

[strikov] Upload to the development release (vivid-proposed): DONE
[strikov] Upload to the current LTS release (trusty-proposed): TODO

[QA Status]

Since there are multiple verifications required, they are listed here as a work item whiteboard status type thing rather than try and track them in a single tag. Please do not mark verification-done or remove block-proposed until all following items have passed. If any of these items fail, this bug should be marked verification-failed immediately.

[sinzui] Upsteam QA test against Vivid: DONE
[sinzui] Upstream QA test against Trusty: DONE
[sinzui] Upstream release process complete: DONE

Manual tests required:

[sinzui] Test juju-quickstart against vivid-proposed: DONE
[sinzui] Test juju-quickstart against trusty-proposed: DONE

The following stakeholders have expressed an interest in performing their own tests and we will wait for a (timely) acknowledgement from them before removing the -proposed blocks. If you also have an interest in testing new Juju releases before they land in an SRU, then please comment in this bug.

Landscape team QA: TODO

Curtis Hovey (sinzui) on 2015-04-15
Changed in juju-core:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Curtis Hovey (sinzui)
tags: added: packaging
affects: juju-core → juju-core (Ubuntu)
Changed in juju-core (Ubuntu):
assignee: Curtis Hovey (sinzui) → nobody
assignee: nobody → Oleg Strikov (strikov)
Changed in juju-core (Ubuntu Trusty):
assignee: nobody → Oleg Strikov (strikov)
Curtis Hovey (sinzui) on 2015-04-16
information type: Public → Private
information type: Private → Public
Curtis Hovey (sinzui) on 2015-04-16
description: updated
Curtis Hovey (sinzui) on 2015-04-16
description: updated
Curtis Hovey (sinzui) wrote :

Ubuntu juju 1.22.1 on vivid is compatible with 1.22.x from upstream Juju. It is suitable deploying and maintaining environments in public and private clouds. Juju is compatible with the versions of quickstart (and deployer) provide by Ubuntu main and proposed.

Note that 1.22.1 does not support systemd, so the case of using local-provider for testing and charm development is not supported.

Removing 'block-proposed' flag to allow juju 1.22.1 to go into Vivid.

description: updated
tags: removed: block-proposed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package juju-core - 1.22.1-0ubuntu1

juju-core (1.22.1-0ubuntu1) vivid; urgency=medium

  * New upstream bugfix release (LP: #1444037).
  * Autopkgtests were changed to switch back to upstart before running their
    workload. This is needed because juju < 1.23 doesn't support systemd.
  * d/patches/fix-detect-new-release.patch: Removed because applied upstream.
  * d/copyright: Updated to reflect changes in the codebase.
 -- Oleg Strikov <email address hidden> Tue, 14 Apr 2015 14:11:54 +0000

Changed in juju-core (Ubuntu):
status: Triaged → Fix Released

Here is the changelog for the package I'm asking SRU for:

juju-core (1.22.1-0ubuntu0.14.04.1) trusty; urgency=medium

  * New upstream release (LP: #1444037).
  * Packaging changes required by the new release and cherry-picked from Vivid:
    - d/tests/fake-future.sh: New ability to generate fake /etc/os-release.
      Change is needed to provide Juju 1.22.1 with an appropriate testbed.
    - d/control: Juju-local now depends on cloud-image-utils | cloud-utils.
      Juju uses ubuntu-cloud template which in turn uses cloud-image-utils.
      Package lxc-templates only recommends cloud-image-utils hence Juju needs
      to require this package directly. Package cloud-utils is mentioned as an
      alternative because cloud-image-utils is not available on precise but we
      want to unify Juju packaging for all supported releases.
    - d/copyright: Updated to reflect changes in the codebase.
  * Compliance to Debian Policy 3.9.6 was declared.

Few comments about the changes:

(1) d/tests/fake-future.sh change is absolutely required by the new release. Without this change future-local-provider and future-manual-provider autopkgtests fail. These tests check if Juju can live inside new development release (when version and codename change) and proposed change extends emulation layer by generating fake /etc/os-release. Juju didn't process /etc/os-release before hence we need this change only for 1.22+.

(2) d/control change has been cherry-picked from Vivid because (a) not fixing this bug will lead to issues with juju when lxc-templates package have been installed w/o recommends (b) we want to minimize packaging delta between supported releases.

(3) d/copyright change is needed because code base changed and we have to react by providing up-to-date d/copyright. It also helps to minimize packaging delta.

(4) Compliance to Debian Policy 3.9.6 has been declared to minimize packaging delta. I don't see any regression potential here.

We still have some delta between 1.22.1 in Vivid and Trusty:

(1) Version in Trusty has explicit build dependency on libgo5 (>= 4.9.1-0ubuntu1) [!amd64 !i386 !armhf]
This change addressed the following issue: https://bugs.launchpad.net/juju-core/+bug/1377325
While 4.9.1-0ubuntu1 is the current version of the package in Trusty I don't see any reason to remove this explicit versioned dependency. It minimizes SRU delta and potential regression risk.

(2) Version in Vivid have autopkgtests modified to revert back to upstart before running tests. This is needed because Juju 1.22.* doesn't support systemd which is default init system in Vivid. This delta will be removed with Juju 1.23 release which supports systemd.

Robie Basak (racb) wrote :

In the Trusty SRU queue so In Progress.

Changed in juju-core (Ubuntu Trusty):
status: New → In Progress

Hello Oleg, or anyone else affected,

Accepted juju-core into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/juju-core/1.22.1-0ubuntu0.14.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in juju-core (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Curtis Hovey (sinzui) on 2015-05-08
description: updated
Curtis Hovey (sinzui) wrote :

I have certified juju 1.20.1 in trusty proposed is compatible with juju agent streams and with the ecosystem of tools in trusty. I verified:
* The binary archs in proposed work with the archs in agent streams.
* Juju is suitable for local testing and charm development
* juju-deployer can deployed the landscape-scalable bundle and a dense bundle to AWS, HP, Joyent and MAAS.
* juju-quickstart (which isn't very reliable in trusty) can still deploy the same bundles to AWS and MAAS
  (If we ever choose to update juju-quickstart in trusty, we will see a big improvement in reliability)

Thanks Curtis! Adding 'verification-done' tag based on your comments.

tags: added: verification-done
removed: verification-needed

There was a typo in the message #8 from Curtis. Juju 1.22.1 has been certified not 1.20.1.
<sinzui> strikov, oops, yes, I do mean *1.22.1*

Curtis Hovey (sinzui) wrote :

@Oleg, et al.
I understand that there is a plan to release a 1.22.4 soon. The intent is to support this version as well as the current 1.23. There are orgs committed to using 1.22 for some time and that there are stability fixes that are being backported.

If we think that Ubuntu users don't want a 1.22.1 then a 1.22.4 in the space of a few weeks, then I think we want to abandon 1.22.1 in proposed. If there is not issue with placing 1.22.1 in updates this week and then placing a 1.22.4 a few weeks later, I will shut up.

Hi Curtis,

To my understanding juju-1.22.1 is not in -updates yet not because we don't want this but because it needs to be in -proposed for 7 days before reaching -updates. This is a standard practice for SRUs. I expect to see it landed into -updates until the end of this week. If juju team wants to have it landed *right now* -- please let us now and we'll discuss it with the SRU team.

Taking into account that 1.22.4 we'll be in -proposed for 7 days as well, I think that we may want to land 1.22.1 first. What is your opinion?

Curtis Hovey (sinzui) wrote :

Hi Oleg.

I am happy to continue with 1.22.1 going into updates first. I am a little concerned about perception of churn in Trusty. Juju 1.22.4 will arrive a few weeks later. What of 1.23.x? 1.23.3 is currently proposed, but Core's desire to put 1.22.4 in means we delay the .1.23 going into trusty. Juju Core wants 1.24.0 in Trusty in June. So I cannot make sense of this schedule. I will take this issue to Juju Core.

I know users are asking that Ubuntu Trusty have each minor release Juju publishes, but if Juju is publishing faster that organisations are willing to adopt, we have a problem. The original plan is a new minor version every 2 months, but the micro versions are ever few weeks ;(.

Curtis Hovey (sinzui) wrote :

I do not want 1.22.1 going into updates because there is a compatibility issue. Bug 1454829 is about a case were a 1.20.11 client cannot talk to an env bootstrapped with. 1.22.x. The certificate rules are different, preventing the client from talking. This is not an issue for envs upgraded from 1.18.x or 1.20.x because the old certs are preserved.

Adding verification-failed based on #14

tags: added: verification-failed
removed: verification-done
Nobuto Murata (nobuto) wrote :

It looks like this bug is superseded by LP: #1469744

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package juju-core - 1.22.6-0ubuntu1~14.04.1

juju-core (1.22.6-0ubuntu1~14.04.1) trusty; urgency=medium

  * No change backport to 14.04 (LP: #1469744). This results in the
    following packaging delta from the previous 1.20.11-0ubuntu0.14.04.1
    in trusty-updates:
    - distro-info added and libgo5 removed from Build-Depends.
    - Standards-Version bumped.
    - cloud-image-utils | cloud-utils added to juju-local Depends.
    - d/copyright updated.
    - dep8 tests updated.

 -- Robie Basak <email address hidden> Wed, 15 Jul 2015 13:09:07 +0000

Changed in juju-core (Ubuntu Trusty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers