cannot bootstrap candidate snap release on kubernetes

Bug #2038299 reported by Alex Lutay
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju

Bug Description


Data team is waiting for Juju 3.1.6 bugfixes and tried to use it for Demo (from 3.1/candidate snap channel), but failed.

MicroK8s cannot fetch OCI Image: jujusolutions/jujud-operator:

The issue:
  Normal Pulling 32s kubelet Pulling image "jujusolutions/jujud-operator:"
  Warning Failed 1s kubelet Failed to pull image "jujusolutions/jujud-operator:": rpc error: code = DeadlineExceeded desc = failed to pull and unpack image "": failed to resolve reference "": failed to do request: Head "": dial tcp i/o timeout
  Warning Failed 1s kubelet Error: ErrImagePull
  Normal BackOff 0s kubelet Back-off pulling image "jujusolutions/jujud-operator:"
  Warning Failed 0s kubelet Error: ImagePullBackOff

The full K8s log:
Reason: is not available here

The bootstrap with --agent-version 3.1.6 doesn't help either.

HUGE thanks to Pedro Guimarães for noticing this!

P.S. juju bootstrap with debug:
09:45:35 INFO juju.environs.bootstrap tools.go:78 looking for bootstrap agent binaries: version=3.1.6
09:45:35 DEBUG tools.go:87 finding agent binaries in stream: "released"
09:45:35 DEBUG tools.go:89 reading agent binaries with major.minor version 3.1
09:45:35 DEBUG tools.go:98 filtering agent binaries by version: 3.1.6
09:45:36 DEBUG build.go:364 forcing version to

Revision history for this message
Alex Lutay (taurus) wrote :

The workaround (from Pedro) is to choose stream 'proposed':

juju bootstrap
--config container-image-stream=proposed \
--config agent-stream=proposed \
--agent-version 3.1.6 \
mycloud mycontroller

I would ask for the fix here, as candidate risk should work out of the box, IMHO. Tnx!

Revision history for this message
Harry Pidcock (hpidcock) wrote :

We'll look at this for future releases, probably in the 4.x series as it will require some changes to our build/release process.

summary: - juju from 3.1/candidate back-off trying to pull missing OCI
- jujusolutions/jujud-operator:
+ cannot bootstrap candidate snap release on kubernetes
Changed in juju:
importance: Undecided → Medium
milestone: none → 4.0-beta1
status: New → Triaged
Revision history for this message
Ian Booth (wallyworld) wrote (last edit ):

The Juju snap provides the Juju *client*. The Juju client is managed separately from the Juju *agent*. A Juju client can bootstrap with any number of agent versions. Just as snap provides a channel to specify what risk to use when asking for the Juju client, so too does the agent metadata allow for a risk to be specified when requesting an agent. Candidate releases of Juju are not stable and so must be opt in, just as candidate snaps are opt in. The Juju agents are cataloged using simplestreams metadata, and the way you specify what risk you want is to use the "agent-stream" config. This is orthogonal to the risk of the snap Juju client. A 3.1.6 candidate client will happily bootstrap a released 3.1.5 controller without any additional args, but if you want to bootstrap a non-released, 3.1.6 candidate controller, you must opt in.

Note the container-image-stream is not needed, that's for lxd/kvm images from memory. You don't even need the agent-version param, just do

juju bootstrap --config agent-stream=proposed mycloud

This is no different from

snap install mysnap --channel=candidate

In the above snap case, "snap" is the cli client (like "juju"), and the "mysnap" is the workload (like the juju controller is).

Revision history for this message
Ian Booth (wallyworld) wrote :

I can see how this can be confusing though. So we need better messaging perhaps.

Changed in juju:
milestone: 4.0-beta1 → 4.0-beta2
Changed in juju:
milestone: 4.0-beta2 → 4.0-beta3
Changed in juju:
milestone: 4.0-beta3 → 4.0-beta4
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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