The command I used is juju deploy --channel "quincy/stable" --base "ubuntu@23.04" ceph-osd
No matter which channel I choose among the ones that support ubuntu 23, the output is the same.
Juju is correctly configured with MAAS as not specifying a base deploys ceph correctly to the first available metal node with the default distro: ubuntu@22.04 LTS.
I noted that setting the MAAS options to deploy ubuntu 23 as default and not specifying the base in the deploy command gives a more useful error:
ERROR cannot deploy bundle: cannot add unit for application "ceph-osd": acquiring machine to host unit "ceph-osd/0": cannot assign unit "ceph-osd/0" to machine 0: base does not match: unit has "ubuntu@22.04", machine has "ubuntu@23.10"
I was using a bundle initially, but am now trying to deploy just ceph via command line.
Using the bundle (configured the same way) gives the same output.
So one issue you’re running into is that the default for the pkg source on quincy is focal/yoga and this conflicts with base 23.04. So you will need to set source explicitly for this combination. You can set it to distro to get the default 23.04 packages. This should result in something like the below:
$ juju deploy --channel "quincy/stable" --config source=distro --base "ubuntu@23.04" ceph-osd
# wait...
$ juju status ceph-osd
Model Controller Cloud/Region Version SLA Timestamp
tst sabaini-serverstack serverstack/serverstack 3.3.0 unsupported 08:43:59Z
App Version Status Scale Charm Channel Rev Exposed Message
ceph-osd 17.2.6 blocked 1 ceph-osd quincy/stable 576 no Missing relation: monitor
Unit Workload Agent Machine Public address Ports Message
ceph-osd/1* blocked idle 1 172.20.0.16 Missing relation: monitor
Machine State Address Inst id Base AZ Message
1 started 172.20.0.16 3389898b-b0cc-4336-ad3b-07c3a7c38e6d ubuntu@23.04 nova ACTIVE
However I do wonder if there’s another issue with MAAS at play here, because the message you posted (cannot assign unit "ceph-osd/0" to machine 0: base does not match: unit has "ubuntu@22.04", machine has "ubuntu@23.10) seems to hint at issues deploying ubuntu@23.04 in the first place, and this happens much sooner, before any source is configured.
Can you deploy other charms to ubuntu@23.04 with your MAAS?
07:39:11 INFO juju.cmd.juju.machine add.go:343 model provisioning
07:39:11 INFO cmd add.go:398 created machine 1
07:39:11 DEBUG juju.api monitor.go:35 RPC connection died
07:39:11 DEBUG juju.api monitor.go:35 RPC connection died
07:39:11 INFO cmd supercommand.go:556 command finished
...
# juju status
Model Controller Cloud/Region Version SLA Timestamp
openstack captainamerica maas-<mymaas>/gen10 3.3.0 unsupported 07:39:16Z
Machine State Address Inst id Base AZ Message
1 pending <my-address>:142:0:1:0 giacomo ubuntu@23.04 gen10 Deploying: Powering on
Deploying ceph-osd to the deployed and working machine gives the same error:
Unfortunately the log messages don’t provide too much info here… Could you check if the juju logs from the controller contain more information? Logs should be on the controller machine somewhere in /var/log/juju/machine-*.log
Not a lot of context but this looks like Juju might have issues contacting the MAAS API, is that possible? Could be networking, a proxy setting getting in the way or something like that?
Hmm. The 502’s don’t seem to appear when I deploy ceph, it might be a temporary network error (we’ve had a couple power outages last week).
What I see in tail when deploying ceph-osd to a deployed ubuntu 23 machine (this one) the controller logs this in machine-0.log:
2024-01-31 09:36:23 INFO juju.apiserver.application.deployfromrepository baseselector.go:121 with the user specified base "ubuntu@20.04/stable"
2024-01-31 09:36:23 INFO juju.apiserver.application.deployfromrepository baseselector.go:121 with the user specified base "ubuntu@22.04/stable"
Hinting that it’s not considering ubuntu@23 as a suitable base
EDIT: the command was the same as before: juju deploy ceph-osd --to 1 --channel latest/edge --config source=distro --base "ubuntu@23.04" --debug
unit-controller-0.log looks ok:
2024-01-31 09:30:16 INFO juju.worker.uniter.operation runhook.go:186 ran "update-status" hook (via hook dispatching script: dispatch)
2024-01-31 09:35:20 INFO juju.worker.uniter.operation runhook.go:186 ran "update-status" hook (via hook dispatching script: dispatch)
I haven’t seen any more logs in the logsink, so I think these are all. Moreover I tested connectivity between the controller and MAAS, and everything looks good:
The source of this was a initrd issue, this is why I wanted to use 23.10.
In the end, I just copied /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-23.10/mantic/stable/boot-initrd to 22.04/jammy/stable/boot-initrd and it worked wonderfully.
Both juju and maas are happy because they think 22.04 is installed, and I get the working initrd.
I was evaluating building custom images as well, but that would require some heavy lifting I can’t do at the moment.
Thanks Peter for your help
