juju lint #1

Supports: focal bionic

Description

"Juju model linter with configurable policy. The following config options must be set: controller-endpoint controller-username controller-password controller-cacert * model-uuid"


Overview

Juju Lint - a Juju model linter with configurable policy.

This charm deploys Juju Lint, along with a script to automate its execution, auto_lint.py. In addition, a crontab is deployed to run auto_lint.py, as well as a Nagios check which analyses Juju Lint output and alerts on errors.

Usage

Deploy this charm with:

juju deploy charm-juju-lint juju-lint

The following model connection config values must be set to allow libjuju to retrieve Juju status output. It is HIGHLY recommended that a new user be created and "read" granted to that user on the model defined:

  • controller-endpoint - A controller API endpoint (syntax: "\<hostname>:\<port>")
  • controller-username - A controller user's username
  • controller-password - The respective controller user's password
  • controller-cacert - The controller CA certificate
  • model-uuid - The model UUID

When setting controller-cacert, the following command sytax is recommended:

juju config juju-lint controller-cacert='
-----BEGIN CERTIFICATE-----
<certificate body>
-----END CERTIFICATE-----
'

The following Juju Lint options are available:

  • lint-config - Juju Lint rules file path
  • lint-override - Hash separated subordinate rule overrides (syntax: "\<name>:\<location>#\<name>:\<location>")
  • lint-loglevel - Logging level, either "CRITICAL", "ERROR", "WARNING", "INFO", "DEBUG", or "NOTSET"
  • lint-logfile - Log file path
  • lint-frequency - Specifies how often Juju Lint is run, in minutes

Juju Lint (upstream)


Configuration

controller-cacert
(string) The controller CA certificate. Value should be base64 encoded.
controller-endpoint
(string) 'A controller API endpoint. (Syntax: "<hostname>:<port>")'
controller-password
(string) The respective controller user's password.
controller-username
(string) A controller user's username.
lint-cloud-type
(string) Specifies the cloud type that will be passed to juju-lint . See juju-lint documentation for more details but the following are typical valid types: openstack, kubernetes. . An empty string (the default) only performs general checks
lint-config
(string) Juju Lint rules file path.
/snap/juju-lint/current/contrib/canonical-rules.yaml
lint-frequency
(int) Specifies how often Juju Lint is run, in minutes.
30
lint-logfile
(string) Log file path.
lint-loglevel
(string) 'Logging level, either "CRITICAL", "ERROR", "WARNING", "INFO", "DEBUG", or "NOTSET".'
INFO
lint-override
(string) 'Hash separated subordinate rule overrides. (Syntax: "<name>:<location>#<name>:<location>")'
model-uuid
(string) The model UUID.
nagios_context
(string) A string that will be prepended to instance name to set the host name in nagios. So for instance the hostname would be something like: juju-myservice-0 If you're running multiple environments with the same services in them this allows you to differentiate between them.
juju
split-nagios-checks
(string) A JSON list of check objects with names and filter rules to be used to create multiple nagios checks instead of a single check with all the juju-lint results. . The default empty string, will generate a single check: "juju_lint_results", that covers all the errors reported by juju-lint. . This requires a version of juju-lint that supports JSON output, and the filtering will happen on the relevant key in the error. Currently only the 'id' and 'tags' fields can be used for filtering. each check is a combination of a nagios check name, a field and a target value to be used for filtering. It is possible have more than one target pattern by separating them using a comma. . Example: [ { "name": "config", "field": "tags", "filter": "config" }, { "name": "misc", "field": "id", "filter": "ops-subordinate-missing,config-isset-check-true" } ] . This would create two checks: juju_lint_results-config (filtering on the 'tags' field, single target) juju_lint_results-misc (filtering on the 'id' field, with two targets)
warn-only
(boolean) Report any issues as WARNING level. This is helpful on initial deployment.