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.
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 10.230.114.21 (install) installing charm software
Machine State DNS Inst id Series AZ Message
0 started 10.230.114.21 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?
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.
@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 freenode.net#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.