ERROR empty id not valid when running upgrade-series

Bug #2025317 reported by Diko Parvanov
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Undecided
Unassigned

Bug Description

In a situation where running upgrade-series on all machines in a model (focal -> jammy) with juju client 2.9.43, (model and controller on 2.9.42) results in "ERROR empty id not valid"

Revision history for this message
Diko Parvanov (dparv) wrote :

db.applications.find({},{"charm-origin.id":1}).pretty() shows a couple of charms without any charm-origin

e.g.:

{
 "_id" : "3f822b7a-63ed-402d-8b2c-c1f25c3f731d:sysconfig-ctrl",
 "charm-origin" : {
  "id" : ""
 }
}

removing those charms unblocked the upgrade, but those were all subordinates, which we can remove, what if this is a principal charm?

Revision history for this message
Joseph Phillips (manadart) wrote :

I assume this model has been upgraded through various versions.

Can you connect to Mongo:
https://discourse.charmhub.io/t/login-into-mongodb/309

And get us the output from "db.applications.find().pretty()"?

There is almost certainly some charm-origin info missing here, as that message is only emitted from charmhub download/refresh calls.

Changed in juju:
status: New → Incomplete
Revision history for this message
Diko Parvanov (dparv) wrote :
Changed in juju:
status: Incomplete → New
Changed in juju:
status: New → Triaged
Revision history for this message
Heather Lanigan (hmlanigan) wrote :

@dparv, What is the charm-url for sysconfig-ctrl? Not all applications require an ID in their charm-origin.

This appears to be duplicate of or related to: https://bugs.launchpad.net/juju/+bug/1999640

Revision history for this message
Diko Parvanov (dparv) wrote :

Everything was deployed form charmhub. Model was not upgraded at all, brand new deployment just for testing the series upgrade of openstack. Where do I check the charm-url (although I already removed the application)

Revision history for this message
Diko Parvanov (dparv) wrote :

some new information from today - the controller was re-used from a previous openstack deployment (same model name + same applications) - would that in any way cause this?

Revision history for this message
Heather Lanigan (hmlanigan) wrote :

Reusing a model name shouldn't have caused the issue, but it might explain why I haven't been able to track this down to the root case. Although I'd expect to see the issue with more charms if that was the case.

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.