I’m trying to create my first charm for MariaDB on my lab (to learn something about that) , it’s the first time that I make something like that and I’m sure that all steps are right. I’ve followed this guide and after the deploy of my charm via JUJU its own status is always in installing mode
$:juju status
Model Controller Cloud/Region Version SLA Timestamp
juju-dev maas-cloud-controller maas-cloud/default 2.7.3 unsupported 21:04:19Z
App Version Status Scale Charm Store Rev OS Notes
layer-lab maintenance 1 layer-lab local 0 ubuntu
Unit Workload Agent Machine Public address Ports Message
layer-lab/0* maintenance idle 0 10.0.0.19 Installing mariadb-server
Machine State DNS Inst id Series AZ Message
0 started 10.0.0.19 juju-dev bionic juju Deployed
Here is my metadata.yaml file
name: layer-lab
summary: <Fill in summary here>
maintainer: Ric Mag <ric.mag@ulab-maas>
description: |
<Multi-line description here>
series: ["bionic"]
tags:
# Replace "misc" with one or more whitelisted tags from this list:
# https://jujucharms.com/docs/stable/authors-charm-metadata
- misc
and layer.yaml file
includes: ['layer:basic','layer:apt'] # if you use any interfaces, add them here
options:
apt:
packages:
- mariadb-server
I think the key here is that once you have finished with the install process in the charm, you need to call set-status again with a new status and message.
@thumper
Following the last link I’ve modify the files inside the hooks directory (install, start, stop and config-changed) and result of its build is that
$:charm build layer-lab --force
build: DEPRECATED: INTERFACE_PATH environment variable; please use CHARM_INTERFACES_DIR instead
build: DEPRECATED: LAYER_PATH environment variable; please use CHARM_LAYERS_DIR instead
build: Please add a `repo` key to your layer.yaml, with a url from which your layer can be cloned.
build: Destination charm directory: /home/richardsith/charms/builds/ngnix-lab
build: Processing layer: layer:options
build: Processing layer: layer:basic
build: Processing layer: ngnix-lab (from ngnix-lab)
proof: I: `display-name` not provided, add for custom naming in the UI
proof: W: Includes template README.ex file
proof: W: README.ex includes boilerplate: Step by step instructions on using the charm:
proof: W: README.ex includes boilerplate: You can then browse to http://ip-address to configure the service.
proof: W: README.ex includes boilerplate: - Upstream mailing list or contact information
proof: W: README.ex includes boilerplate: - Feel free to add things if it's useful for users
and run the deploy, now its JUJU status is:
$:juju status
Model Controller Cloud/Region Version SLA Timestamp
juju-dev maas-cloud-controller maas-cloud/default 2.7.3 unsupported 20:38:39Z
App Version Status Scale Charm Store Rev OS Notes
layer-lab active 1 layer-lab local 0 ubuntu
Unit Workload Agent Machine Public address Ports Message
layer-lab/0* active idle 0 10.0.0.19 Started with message:
Machine State DNS Inst id Series AZ Message
0 started 10.0.0.19 juju-dev bionic juju-dev Deployed
Name your charm “lab”, instead of layer-lab. It’s a convention for the code of a reactive charm to name it layer-xxxx, rather than to use it in the name.
Status indications are informative only. They don’t do anything. It’s the charm author that should set those to indicate what goes on in the charm. The changes are auditable via ‘juju show-status-log’
If you don’t know the hooks state machine, go back to that before you start with reactive. [Draft] Charm hooks
I wrote a tutorial about hook charms you might want to explore [Tutorial] A tiny hooks charm It needs an update I realize, but it’s better in my opinion than the reactive one if you are new to juju. But it’s perhaps a matter of preference.
There is an authentication limitation in how the GUI interacts with Juju around displaying icons for local charms which is probably what you’re seeing there. We won’t be addressing this in the GUI but it’s on our roadmap to resolve in the upcoming replacement for the GUI, the Juju Dashboard.
thanks a lot for your tips. This is my first time that I create a charm and I not sure the procedure is right, I’ll see your tutorial immediately to correct my issue., in case I’ll ask your a tip…
here is my first stop …
I’ve read your tutorial and followed all steps, you talk about snaps package and while I was modifying my charm I’ve noted that Ngix or Apache is not present yet in snap store.
So my doubt/question is:
Is it right to use snap as main tool to create a charm when in its own store are not present the main packages yet???
You can use any package manager within a charm or even upload files to the juju controller as a ‘resource’. I used snap in my tutorial just show the capability.
So, if you intend to install nginx/apache you can do that just as well with apt.
Implement the install hook. Don’t start any services here as this hook is mainly to get all components/packages/artifacts/files in place and available on the unit.
Implement the config-changed hook. Configure the components here, and, this is a good place to handle restarts/reload/behavior of services when the charm config has been changed.
Implement the start hook. Bring up the service if all conditions to do so are met. Like config, available dependent services etc.
Implement relation- hooks (if you have any relations)
Implement the upgrade-charm hook. This is where you handle the charm upgrade. Mind that this is not the same as upgrading the encapsulated software, which is likely a separate process.
Implement any other non core hooks, like storage, metrics etc.
Implement some good juju actions to assist an operator to manage your charm/service.
Our experience at Canonical is yes. Many charms install snaps, including several that underpin our commercial products. Charmed Kubernetes is one example.
Another person to pull into the thread is @hatch. He prefers to write simple charms, rather than using frameworks.
Your workflow mostly matches mine. Some minor additions.
Relations will often provide you with info that you need to set your application’s configuration settings. To extract that data, retrieve them from *-relation-changed.
config_changed does most of the work. Its role is generally to write a systemd “unit file” (look for “Example 2. Overriding vendor settings”) and/or call systemctl try-reload-or-restart <service>.
start does almost nothing. Perhaps systemctl try-restart <service>. The start hook is only executed once (although from Juju 2.8, it will be executed when the machine restarts).
you right about that, but at moment, if you check in snap store for example Apache, Nginx, Zabbix and many other are not present.
Snap is a great project and I’m so happy if that will replace apt…I hope soon, but at moment if I have to use that in a product environment is not ready to replace totally apt as for Juju, where some charms are available for some ver. of Ubuntu and not for other… and this is a very limit to build a stable environment for a company. This is only a my current opinion and I hope that will replace apt soon, and Juju as a perfect service modelling tool
As wrote above, I’m learning how to build a base charm and my first stop has been Nginx on Juju and on snap ,
Switching between apt and snap is not straight firward like that since these systems, dpgk vs snap, work very differently.
You need to understand those differences and alter the charm appropriately.
That could be stuff such as how your software is being configured, started and integrated with axillary systems.
In your case, nginx, is available through a few charms already, taking height for many use-cases. You might want to check those out? tls-termination-proxy is one.
That said, if you still want to try install nginx with apt, you must make sure apt is run with the correct parameters for running in non interactive mode emitting ‘yes’ when asked for confirmation of install: apt -y install nginx
hi there,
I need help, after to run that (it’s a lab)
$: charm build nginx
build: DEPRECATED: INTERFACE_PATH environment variable; please use CHARM_INTERFACES_DIR instead
build: DEPRECATED: LAYER_PATH environment variable; please use CHARM_LAYERS_DIR instead
build: Please add a `repo` key to your layer.yaml, with a url from which your layer can be cloned.
build: Destination charm directory: /home/richardsith/charms/builds/nginx
build: Processing layer: layer:options
build: Processing layer: layer:basic
build: Processing layer: nginx (from nginx)
proof: I: `display-name` not provided, add for custom naming in the UI
proof: W: README.md includes boilerplate: Step by step instructions on using the charm:
what do mean the first and last lines and where I’ve to correct them? because I don’t understand what I’ve to do…
thanks in advance
I’ve create a virtual environment where I’ve installed MAAS and JUJU with Ubuntu 20.04 , as the previous lab with Ubuntu 18.04 I’ve tried to create a charm. Here is my metadata files:
name: ngnix-lab
summary:
maintainer: Riccardo Magrini
description: |
This is my first JUJU charm
series: ["focal"]
tags:
- application
provides:
web-engine:
interface: nginx-vhost
indicated Focal as series. But running that:
$:charm proof nginx-lab/
I: `display-name` not provided, add for custom naming in the UI
E: missing series: must be a list of series names
W: README.md includes boilerplate: Step by step instructions on using the charm:
W: README.md includes boilerplate: You can then browse to http://ip-address to configure the service.
W: README.md includes boilerplate: - Upstream mailing list or contact information
W: README.md includes boilerplate: - Feel free to add things if it's useful for users
I: all charms should provide at least one thing
…
