Canonical Juju

Juju should use bundled jujud if not matching agents found in streams

Bug #1629376 reported by Nicholas Skaggs
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Invalid
Critical
Unassigned
juju-core (Ubuntu)
Fix Released
Undecided
Nicholas Skaggs
Xenial
Fix Released
High
Nicholas Skaggs

Bug Description

Since --upload-tools is now no longer needed, juju needs to fallback to using bundled jujud in the case where no matching agents are found in streams. For example,

6:38:07 INFO juju.environs.manual init.go:120 series: zakkety, characteristics: arch=amd64 cpu-cores=1 mem=3855M
..
16:38:07 INFO cmd cmd.go:129 Looking for packaged Juju agent version 2.0-beta18 for amd64
...
16:38:08 INFO juju.environs.bootstrap tools.go:74 found 15 packaged agent binaries
..
16:38:08 ERROR cmd supercommand.go:458 failed to bootstrap model: no matching tools available
16:38:08 DEBUG cmd supercommand.go:459 (error details: [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:738: failed to bootstrap model} {github.com/juju/juju/tools/list.go:19: no matching tools available}])

In this example, beta18 is a released version, and 15 agents are found. However, none of them match my crazy series. Juju should still use the bundled agent automatically. Note, passing --build-agent requires me to rebuild an agent in this case; not something I can/should need to do on a client machine.

[SRU Information]

[Impact]
The autopkgtest for future-manual-provider ensuring juju works with the next release before a juju update will be disabled per the bug.

[Verification]
The autopkgtest future-manual-provider should now be skipped with
SKIP: Juju won't bootstrap unknown without published agent (LP:1629376)

[Regression Potential]
None. The package won't make it out of proposed, as the test will currently fail as-is.

[Other]
This should have no impact on end users of the package; the verification can be done by viewing the test results under http://autopkgtest.ubuntu.com/packages/j/juju-core/.

See original description
Nicholas Skaggs (nskaggs)
description: updated
tags: added: ci regression
Curtis Hovey (sinzui)
tags: added: packaging
Changed in juju:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 2.0.0
Revision history for this message
Curtis Hovey (sinzui) wrote :

This ultimately a blocker for putting Juju into Ubuntu. They require juju clients to work with the next Ubuntu release. The next-release test was put in place because Juju clients fell over when they didn't recognise their host series.

There may come a time when Ubuntu only get clients, and the package test will need to switch to the current LTS. It is possible to change the package tests to do this

Alexis Bruemmer (alexis-bruemmer)
Changed in juju:
assignee: nobody → Alexis Bruemmer (alexis-bruemmer)
Revision history for this message
Ian Booth (wallyworld) wrote :

I am not sure that Juju should be changed to account for streams being out of date. The only way the suggested scenario can happen is when a new Ubuntu series is released and streams have not yet been updated. Our streams publication should be ahead of the curve and ensure that streams are always current. Juju clients will work with Ubuntu+1, so long as the streams contain that new series (IIANM)

Alexis Bruemmer (alexis-bruemmer)
Changed in juju:
status: Triaged → Invalid
Alexis Bruemmer (alexis-bruemmer)
tags: added: ateam
Revision history for this message
Curtis Hovey (sinzui) wrote :

GThe manual test in question is not only invalid, it is dangerous. A valid production use of Juju is to manually provision the current stable. the insane test is 1. provisioning a non-lts, and 2, provisioning itself. Juju Will do BAD things if it used to manually provision its own localhost.

Curtis Hovey (sinzui)
Changed in juju:
milestone: 2.0.0 → none
assignee: Alexis Bruemmer (alexis-bruemmer) → nobody
Revision history for this message
Nicholas Skaggs (nskaggs) wrote :

"The only way the suggested scenario can happen is when a new Ubuntu series is released and streams have not yet been updated. "

That is the exact case we are testing. But doesn't it seem silly for juju to not use the built in jujud if one exists? Why is it ok for juju to use an agent if it builds it on the spot, but it won't use it if it is merely packaged as part of it?

When would a packaged version of jujud be used?

Nicholas Skaggs (nskaggs)
Changed in juju-core (Ubuntu):
status: New → In Progress
assignee: nobody → Nicholas Skaggs (nskaggs)
Nicholas Skaggs (nskaggs)
description: updated
description: updated
Mathieu Trudel-Lapierre (cyphermox)
Changed in juju-core (Ubuntu Xenial):
status: New → In Progress
Changed in juju-core (Ubuntu):
status: In Progress → Fix Released
Changed in juju-core (Ubuntu Xenial):
assignee: nobody → Nicholas Skaggs (nskaggs)
importance: Undecided → High
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Nicholas, or anyone else affected,

Accepted juju-core into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/juju-core/2.0.0-0ubuntu0.16.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 Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Nicholas Skaggs (nskaggs) wrote :

As per http://autopkgtest.ubuntu.com/packages/j/juju-core, the test was skipped and the autopkgtest suite succeeded.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package juju-core - 2.0.0-0ubuntu0.16.04.2

---------------
juju-core (2.0.0-0ubuntu0.16.04.2) xenial; urgency=medium

  * DPKG_MAINTSCRIPT_ARCH doesn't work in .config, use dpkg check (LP: #1614969)

 -- Nicholas Skaggs <email address hidden> Mon, 31 Oct 2016 15:55:49 -0400

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.