Deploying charm on same host, bionic works, focal fails

Hej,
had problems deploying openstack bundle-70, worked my way back to that it seems to be an issue when deploying with focal as series.

Im running a MAAS environment, and deployed cs:mongodb-57 on the same host, if --series=bionic is used, the deployment works fine. If --series=focal, then the deployment ‘works’ on the host (Deployed), but juju keeps "waiting

ats@kmaas:~$ juju status
Model Controller Cloud/Region Version SLA Timestamp
testmod kmv2 KMloud/default 2.7.1 unsupported 15:30:10+01:00

App Version Status Scale Charm Store Rev OS Notes
mongodb waiting 0/1 mongodb jujucharms 57 ubuntu

Unit Workload Agent Machine Public address Ports Message
mongodb/2 waiting allocating 4 XYZ.14 waiting for machine

Machine State DNS Inst id Series AZ Message
4 pending XYZ.14 idrac-ghzfk03 focal default Deployed

As juju isn’t really ready, manual ssh to the host XYZ.14 is the only thing that works.
Once connected, the only hint is that in /var/log/cloud-init-output.log

----begin

  • ln -s 2.7.1-focal-amd64 /var/lib/juju/tools/machine-4
  • echo Starting Juju machine agent (service jujud-machine-4)
    Starting Juju machine agent (service jujud-machine-4)
  • mkdir -p /lib/systemd/system/jujud-machine-4
  • cat
  • chmod 0755 /lib/systemd/system/jujud-machine-4/exec-start.sh
  • cat
  • /bin/systemctl link /lib/systemd/system/jujud-machine-4/jujud-machine-4.service
    Created symlink /etc/systemd/system/jujud-machine-4.service → /lib/systemd/system/jujud-machine-4/jujud-machine-4.service.
  • /bin/systemctl daemon-reload
  • /bin/systemctl enable /lib/systemd/system/jujud-machine-4/jujud-machine-4.service
    Created symlink /etc/systemd/system/multi-user.target.wants/jujud-machine-4.service → /lib/systemd/system/jujud-machine-4/jujud-machine-4.service.
  • /bin/systemctl start jujud-machine-4.service
    Failed to start jujud-machine-4.service: Unit jujud-machine-4.service not found.
    Cloud-init v. 20.3-2-g371b392c-0ubuntu1~20.04.1 running ‘modules:final’ at Tue, 01 Dec 2020 12:48:05 +0000. Up 138.92 seconds.
    2020-12-01 12:48:41,723 - cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in /var/lib/cloud/instance/scripts)
    2020-12-01 12:48:41,727 - util.py[WARNING]: Running module scripts-user (<module ‘cloudinit.config.cc_scripts_user’ from '/usr/lib/python3/dist-pac
    Cloud-init v. 20.3-2-g371b392c-0ubuntu1~20.04.1 finished at Tue, 01 Dec 2020 12:48:41 +0000. Datasource DataSourceMAAS [http://194.47.151.84:5240/M
    —end

But I cant decode that information, did it fail to download something? Something that’s missing?

As it works for bionc on the same host, I kind of ruled out MAAS host config messing things up (but failure is always an option right?).

Any hints, or tips on what could cause this problem?

BR/Patrik

FWIW, I was able to deploy the mongodb charm on the focal series using a KVM-based MAAS (v.2.6.2) node. I would suggest you check the logs of the MAAS host at:

  • /var/log/maas/rsyslog (apt install)
  • /var/snap/maas/common/log/rsyslog (snap install)

My juju status output:

Model    Controller  Cloud/Region    Version  SLA          Timestamp
mongodb  xxxxxx      xxxxxx/default  2.8.6    unsupported  16:29:39Z

App      Version  Status  Scale  Charm    Store       Rev  OS      Notes
mongodb  3.6.8    active      1  mongodb  jujucharms   57  ubuntu  

Unit        Workload  Agent  Machine  Public address  Ports                                    Message
mongodb/0*  active    idle   0        10.200.100.27   27017/tcp,27019/tcp,27021/tcp,28017/tcp  Unit is ready

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

I also found LP #1860432.

I don’t believe that Juju 2.7 supports focal.

Is there a reason that you’re deploying w/ a relatively early version of 2.7, rather than 2.8 (or the latest version of 2.7)?

Good catch @petevg :slight_smile:

Limited resources, hoped my controller could handle it.

Where do I fill in a feature request? It seems that it could be good if Juju checked what series it’s asked to deploy, and compare that with its own capabilities before it tries to deploy.

Would have helped me.

Thanks for the help, stay safe, and have a nice day.

BR/Patrik

HI @pal-arlos,

Please feel free to file a bug at Bugs : juju. Add the community-feedback tag, and we’ll track it appropriately. (Or ping us here with a link to the bug, and we’ll tag it.)

(My understanding, btw, is that we should be more clear about unsupported series – I’m not sure quite what broke here, but we’d be happy to investigate.)

~ PeteVG

Hi @petevg,

think this is the link; Bug #1906790 “Juju tries to deploy hosts with incompatible seri...” : Bugs : juju

Stay safe and have a nice day!

BR/Patrik