Juju status, status and workload unknown

help-needed

#1

I’m trying to use juju charms to configure day1/2 containers of OSM.
Specifically I’m using the vim-emu as VIM.

Anyway, looks like deploying the charm (I hope I’m using the right term) fails.
After juju switch, this is what juju status shows:

$ juju status
Model                                 Controller  Cloud/Region         Version  SLA          Timestamp
94d0fe14-d2e3-49cc-bdeb-bc291ccd871b  osm         localhost/localhost  2.6.10   unsupported  18:20:50Z

App                           Version  Status   Scale  Charm   Store  Rev  OS      Notes
simple-charmed-nsd-test-b-aa           unknown      1  simple  local    0  ubuntu  

Unit                             Workload  Agent  Machine  Public address  Ports  Message
simple-charmed-nsd-test-b-aa/0*  unknown   idle   0        10.149.5.53            

Machine  State    DNS          Inst id        Series  AZ  Message
0        started  10.149.5.53  juju-bc2a17-0  xenial      Running

End of logs:

$ juju debug-log
...
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 INFO juju.worker.upgrader abort check blocked until version event received
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 INFO juju.worker.upgrader unblocking abort check
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 INFO juju.worker.upgrader desired agent binary version: 2.6.10
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.dependency "upgrade-check-flag" manifold worker stopped: gate unlocked
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.dependency "upgrade-check-flag" manifold worker started at 2019-11-04 16:49:59.142202307 +0000 UTC
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.dependency "migration-fortress" manifold worker started at 2019-11-04 16:49:59.152457658 +0000 UTC
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.dependency "migration-minion" manifold worker started at 2019-11-04 16:49:59.161836873 +0000 UTC
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 INFO juju.worker.migrationminion migration phase is now: NONE
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.dependency "leadership-tracker" manifold worker started at 2019-11-04 16:49:59.173809096 +0000 UTC
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.logger initial log config: "<root>=DEBUG"
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.dependency "api-address-updater" manifold worker started at 2019-11-04 16:49:59.173875235 +0000 UTC
unit-simple-charmed-nsd-test-b-aa-0: 16:49:59 DEBUG juju.worker.leadership simple-charmed-nsd-test-b-aa/0 making initial claim for simple-charmed-nsd-test-b-aa leadership

Does it say anything?
Can I somehow debug / understand it?

Thanks


#2

juju workload status reflects what the charm tells juju.
If the charm does not inform juju what the workload status is, juju will show unknown.

The charm needs to use the status-set hook command (there’s also a Python charmhelper function) to report one of waiting, blocked, maintenance, or active, with an optional message.

This is done per unit and the overall application workload status will aggregate these. eg if all units are active then so too is the application, but if one unit is blocked, the application will also show blocked. The unit leader can also set the application status directly to override the default aggregation.


#3

Thanks for the reply.
I’ve built this charm using a “standard” way (AFAIU):

charm create mycharm

I see this line in mycharm/actions/myaction:

set_state('actions.{}'.format(action_name()))

Is that what you mean?

There are also these imports under reactive/mycharm.py:

from charms.reactive import when, when_not, set_flag
from charms.reactive import (
    remove_state as remove_flag,
    set_state as set_flag,
    when, when_not
)

Hmm,
Should I somewhere set this state?

I thought I should automatically get this functionality, because I used the standard way to create a charm.


#4

Every charm is different in the hooks it responds to and the events it wants to deal with. This is also true of the status messaging as charms will go through their own steps of state. The charm you have when you use the template is a simple thing that doesn’t really perform anything.

Take a look at some existing charms to get an idea of things. For instance, there’s a simple Ubuntu charm here: https://jaas.ai/ubuntu. You can download it with charm pull cs:ubuntu or use the download zip link on the right side of the web page.

It really just places itself on an Ubuntu machine from the cloud and sets a hostname value but you can see it sets a status and a uses state.


#5

Thank you!
Of course I was missing this

def install_simple():
    ...
    status_set('active', 'Ready!')

Now I got this error Verification failed: Invalid IP address:

Unit                             Workload  Agent  Machine  Public address  Ports  Message
simple-charmed-nsd-test-b-aa/0*  blocked   idle   0        10.133.146.38          Verification failed: Invalid IP address.

Hmmmm,
Any quick hints ?
I don’t see any ERROR in juju debug-log.


#6

So that’s not an error from the debug-log but that the unit placed that as a status message. That should be in the charm somewhere. You might run a git grep Verification on your charm repository and see if you find any hits.


#7

There’s some most excellent charm writing tutorials posted by a Juju user @erik-lonroth . They will be of help in getting started with charm writing if you’re new to it.


#8

Thanx for the creds @wallyworld, I would also suggest for a beginner to do this tutorial as well to get a feeling about hooks, which might be an equal good beginning for a starting up charmer.