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?
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.
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.
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.
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.
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.
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.
