Overrides

What overrides are for

Every change CloudWady makes on your servers is a run of playbooks, the steps it takes, and templates, the files it writes, such as an app's Docker Compose file or its Odoo configuration. An override replaces one of them with your own version. Runs then use yours instead of CloudWady's: everywhere in a namespace, or only for one project, environment, app, URL or server, or for every record of one kind.

Use one when something you need has no setting in the dashboard. Weigh it first. An override takes that file or step over from CloudWady: fixes CloudWady makes to it later do not reach the runs that use yours (see Overrides and platform updates), and a mistake in it fails those runs or breaks what they set up.

In the sidebar, Overrides has Templates and Playbooks. The section needs the White Label add-on; without it, it shows locked. Maintainers see the overrides; Admins add, change and remove them. See Who may do what.

Template Overrides

Your own versions of the files CloudWady's runs write, such as an app's Docker Compose file or its Odoo configuration.

You can

• Switch an override on or off by clicking its tick or cross under Active.
• Add one with Add Override, or change one with the pencil, in the editor.
• Delete one with the bin, after you confirm.
• List every override that is not healthy with Needs Attention (Health).
• See which override a run would use with Test Resolution.

Good to know

• A change is stored at once and runs nothing: the next run in its scope that writes that file uses it.
• The most specific comes first: Priority is 30 for a record, 20 for a kind, 10 for the namespace (Which override a run uses).
• An override takes the file over: fixes CloudWady makes to it later do not reach your runs (Overrides and platform updates).
• Maintainers see the list; switching, adding, editing and deleting take the Admin role.
• Overrides need the White Label add-on.

Playbook Overrides

Your own Ansible plays in place of CloudWady's: each one replaces the whole play of one step of a run.

You can

• Filter, add, edit, switch and delete them as for Template Overrides.
• See which playbook each one replaces under Base Playbook.
• Try one on a development app first: scope it to that app, run it, then widen the scope.

Good to know

• Your play runs on your servers as root: a wrong task can change or delete anything there, your apps' data included.
• Nothing checks your play before it runs, so keep it as close to CloudWady's as you can.
• When what you need to change is a file, prefer a template override.
• Each run that reaches that step in the override's scope plays yours instead, from the next run on.
• Maintainers see the list; switching, adding, editing and deleting take the Admin role.

Adding or editing an override

Add Override, or the pencil on a row, opens the editor in place of the list, titled Create Template Override or Edit Playbook Override and so on. It has three parts, described below. Save Override on the title row stores it; Back returns to the list without saving. When you edit one, the title row shows its priority and what it replaces, and a warning shows when its health is not Healthy.

Save checks that a namespace, a name and a base are set, that a record has its kind, and that there is content or a replacement. Only one override may target the same template or playbook at the same place: a second one is refused.

Which override a run uses

Each time a run writes a template or plays a playbook, CloudWady looks for an active override of it in the namespace of the record the run is for. It starts at that record and moves up through its parents: from a URL to its app, its environment and its project. At each step it takes an override for that exact record first, then one for every record of that kind. A namespace-wide override applies when nothing narrower matches. A run for a server looks at that server, then at every server.

So an override for one app beats one for all apps, which beats one for its project, which beats a namespace-wide one. The Priority column shows the level: 30 for a record, 20 for a kind, 10 for the namespace. Without a match, the run uses CloudWady's own version. Each use adds one to Usage and sets Last Used.

An override in one namespace never applies to another, client namespaces included. A run that is already going keeps what it started with.

Health

Each override has a health state, shown on its row when it is not healthy, with a line on why. The Needs Attention filter lists them all.

A state is a warning, not a block: runs keep using the override until you change or remove it.

Overrides and platform updates

An override belongs to your namespace, not to CloudWady's set of templates and playbooks. A platform update does not change it, switch it off or remove it.

That is also its cost. Your content stays as you wrote it, so a fix CloudWady makes to the base does not reach the runs that use your override. When the base changes more than 30 days after your content, the override shows Stale. Open it, click Reset to Default to load the current base, put your change back in, and save.

An override that uses a replacement follows that template as it is updated. If CloudWady removes the base, the override is removed with it.

Applying and removing an override

An override applies from the next run in its scope that uses its base; saving it runs nothing. To put it on an app now, run what writes that file or plays that step, for example the app's next Update (see Deploy, update or build) or Apply Config (see Other actions).

To stop using one, you have two ways:

• switch it off with the Active button on its row: the override and its content stay, ready to switch on again;
• delete it with the bin, after you confirm. That cannot be undone.

Either way, the next run uses CloudWady's own version again. Files your override already wrote on a server stay as they are until a run writes them again. Each of these takes the Admin role.

Who may do what

Overrides need the White Label add-on. Who may do what there is the same in every environment, production included: an override scoped to a production app is changed by the same roles as any other.

See Access levels for every role.