Workload stuck in maintenance status

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

my node on MAAS

on JUJU gui

someone can help me???thanks

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

in JUJU gui


but I’m not sure.

I’ve used this link to create the icon for my first charm but nothing, there is always that:

Any suggests? I’ve to make something else?
thanks

A few hints:

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

1 Like

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.

1 Like

ok perfect, thanks a lot for your answer

Hi @erik-lonroth,

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…:wink:

1 Like

Just ask if you get stuck m8.

here is my first stop :sweat_smile:
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??? :thinking:

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.

Here is another example hooks charm , using ‘yum’ telegraf prometheus | Juju

1 Like

@riccardo-magrini

My tactic for writing simple charms is:

  1. 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.
  2. 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.
  3. Implement the start hook. Bring up the service if all conditions to do so are met. Like config, available dependent services etc.
  4. Implement relation- hooks (if you have any relations)
  5. 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.
  6. Implement any other non core hooks, like storage, metrics etc.
  7. Implement some good juju actions to assist an operator to manage your charm/service.

That’s a fairly normal workflow.

@timClicks @rick_h @jameinel @szeestraten is this workflow yours too in hooks only charms?

1 Like

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 :wink:
As wrote above, I’m learning how to build a base charm and my first stop has been Nginx on Juju and on snap :thinking:,

We’ll see in U20.04 :wink::wink:

Hi @erik-lonroth,

I’ve tried to use your install file on tiny-python replaced snap with apt

Screenshot%20from%202020-04-19%2023-53-34

but at the end of the deploy I have an error

in the juju debug-log I’ve this issue:

ERROR juju.worker.uniter.operation hook "install" failed: exit status 1

or being apt I have to change something else?

thanks a lot.

A few comments:

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

1 Like

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

An environment variable has changed name. Just rename it. unset INTERFACE_PATH export CHARM_INTERFACES_DIR=path-to-interfaces

This is a Warning only, indicating that you didn’t add documentation of your charm.

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

looking that there is an error:

E: missing series: must be a list of series names

is changed something ? thanks