Series support is either very confusing or just broken...?

juju deploy cs:~containers/calico --series focal

results in

ERROR calico is not available on the following series: focal not supported

But the calico charm referenced explicitly says it supports focal, both in its page on the charms store and in its metadata.

Am I missing something really obvious? Or is this a bug?

On the face of it, it certainly looks like a bug somewhere. Is it possible that focal images are not yet available for your cloud?

Inspecting the charm’s metadata, it certainly declares its support for focal:

$ charm show ~containers/calico
A robust Software Defined Network from Project Calico

Name			calico
Owner			containers
Revision		698
Supported Series	xenial, bionic, focal
Tags			networking
Subordinate		true
Promulgated		false
Home page
Bugs url
Read			everyone
stable			true		
beta			true

Edit: I’ve just deployed an model on AWS with this charm to focal and it’s working fine:

juju deploy ~containers/etcd --series focal
juju deploy ~containers/calico --series focal
juju deploy ~containers/easyrsa --to 0 --series focal
juju deploy -n2 cs:~containers/kubernetes-worker --series focal
juju relate calico etcd
juju relate calico kubernetes-worker
juju relate etcd easyrsa

I’m using MaaS as the cloud. Using a model with default series set to focal. Machines can be added without errors, but I’ve not managed to deploy anything to focal without --force. Same thing happens with other charms.


juju deploy ~containers/etcd

results in

ERROR etcd is not available on the following series: focal not supported

To clean up before doing this, I ran

juju destroy-model default --yes
juju add-model default
juju switch default
juju model-config default-series=focal

Does this mean that focal support is just not enabled on MaaS? Where could I find out what series a cloud supports? (MaaS does not seem to have any trouble deploying focal machines either manually or through Juju)

FWIW I was able to deploy using MAAS (v.2.6.2) as the backing cloud:

juju add-model discourse
juju model-config default-series=focal
juju deploy ~containers/etcd
juju status

Model      Controller   Cloud/Region  Version  SLA          Timestamp
discourse  mymaas       maas/default  2.7.5    unsupported  05:00:25Z

App   Version  Status       Scale  Charm  Store       Rev  OS      Notes
etcd           maintenance      1  etcd   jujucharms  501  ubuntu  

Unit     Workload     Agent      Machine  Public address  Ports  Message
etcd/0*  maintenance  executing  0          (install) installing charm software

Machine  State    DNS            Inst id       Series  AZ       Message
0        started  virt-node-10  focal   default  Deployed

I’m using MaaS 2.7.0 and Juju 2.7.6, so assuming there are not regressions, then the message

ERROR {xxxx} is not available on the following series: focal not supported

must be triggered for some other reason. Is there anywhere I can get more information and find out? Logs? Diagnostics? Debug? Where to dig in the source code?

I’ve finally discovered

juju debug-log --replay --include=application-name

and the other logging and debugging tools in the documentation. I’m working my way through to find out what is going on, but so far it doesn’t seem to offer much help as to why this is giving the particular error.

I appreciate that this must be incredibly frustrating for you. Well done on your perseverance.

Working with Juju has been a generally really pleasant experience - the documentation is good, and mostly stuff just works. So thanks! With the web gui, lots of stuff is made ‘explorable’ which really adds to usability… i.e. the option being shown in the gui just lets you know that it’s there and can be used - which makes finding out about certain parts of functionality really easy without reading the documentation.
There are a few bits of charms which don’t work - or which don’t work with non-standard options chosen on the underlying cloud, and surfacing error messages more obviously and easily would really help with that (particularly in the web interface and the juju status output). If something breaks or an agent gets into a loop of things going wrong, etc - just having the latest error message from the debug logs displayed on those screens - or even a hint to use the CLI logging tools - would improve usability a huge amount. Also just a page to view logs in the web gui would be awesome, again just as a way to easily show users a useful feature without going to the docs.

1 Like

@tombull did you ever figure anything out with this? I’m having the exact same issue deploying with MaaS. Every charm I deploy just says that it doesn’t have focal support even though they do. Thanks in advance!

Hey @jbrisko, I never really fixed this - I spent days trying to get stuff working on focal - and I definitely made progress, to the point of an almost-working setup - but I ended up giving up and having everything run on bionic because there were just unexplained problems with the installation on focal. In the end, I’ve basically completely given up on juju. I still use MaaS, which is great - but my main use case for juju was charmed kubernetes. I’ve tried rancher, and it’s just miles better in almost every way for setting up kubernetes on bare metal or cloud, so I’ve pretty much given up on juju.

I’m certainly sorry to hear that this has been a frustrating experience. I even reached out internally, and we are seeing things work successfully internally. There are tools like “juju debug-log” that can help diagnose what is going wrong, and you can reach out to us on irc #juju if you want a bit more live interaction.

The current error that I see (juju-2.9 development) if you specify a series that the charm itself doesn’t support is:

$ juju deploy . --series groovy
ERROR series "groovy" not supported by charm, supported series are: bionic,focal,xenial,trusty

So that is what it would look like if something like ‘etcd’ did not declare support for focal. And there isn’t a lot that would be logged, because we would not allow you to start the application if it doesn’t declare support for it. (You can override this with juju deploy foo --series X --force but we require force because there is limited expectation that an arbitrary charm will know how to configure the application on an arbitrary series.)

You can also supply “–debug” to the deploy command, eg juju deploy foo --debug which will log what the client is trying to do. Because you’ve been editing it out, it is unclear which application is actually failing to deploy.