Comment 5 for bug 1516989

Revision history for this message
Cheryl Jennings (cherylj) wrote :

I see what the problem is now. This was injected when the unit status was split into unit / unit agent status. Starting in 1.24, we key the unit status with an id of "u#<unit name>#charm", whereas older versions just used "u#<unit name>". The key "u#<unit name>" is now used for the unit agent status.

There does not seem to be an upgrade step to create the unit / workload statuses, so when we try to query the unit status, we get an error back. In running the full status, this error is ignored, and a nil status is displayed for the workload. You can see this when we just run juju status: http://paste.ubuntu.com/13538895/
In the above paste, the ubuntu and ubuntu2 workload-status is nil. But, ubuntu3, which was deployed post-upgrade to 1.25, has a valid status.

When running juju status to query a specific service, it will error because the workload status does not exist.

An upgrade step is needed to correctly create the unit / workload status. If needed, it may be possible to create a script to insert the values into an existing environment. But, I need to defer that to someone who has more knowledge of mongodb internals. Going to ask Menno for help on this part.