The Equinix Metal cloud and Juju

This document describes details specific to using your existing Equinix Metal cloud with Juju.

See more: Equinix Metal

When using this cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.

As the differences related to (1) are already documented generically in the rest of the docs, here we record just those that follow from (2).

Notes on juju add-cloud

Type in Juju: equinix

Name in Juju: equinix

Notes on juju add-credential

Authentication types

access-key

Attributes:

  • project-id: Packet project ID (required)

  • api-token: Packet API token (required)

Supported constraints

CONSTRAINT

conflicting:

supported?

- allocate-public-ip

TBA

- arch

TBA

- container

TBA

- cores

TBA

- cpu-power

TBA

- image-id

✕

- instance-role

TBA

- instance-type

TBA

- mem

TBA

- root-disk

TBA

- root-disk-source

✕

- spaces

✕

- tags

TBA

- virt-type

TBA

- zones

Supported placement directives

PLACEMENT DIRECTIVE

<machine>

TBA

subnet=<subnet>

✕

system-id=<system ID>

✕

zone=<zone>

TBA

Other notes

Before deploying workloads to Equinix metal:
Due to substrate limitations, the Equinix provider does not implement support for firewalls. As a result, workloads deployed to machines under the same project ID can reach each other even across Juju models. Deployed machines are always assigned both a public and a private IP address. This means that any deployed charms are implicitly exposed and proper access control mechanisms need to be implemented to prevent unauthorized access to the deployed workloads.