List of supported clouds > Equinix Metal
This document describes details specific to using your existing Equinix Metal cloud with Juju.
See more: Equinix Metal
When using the Equinix Metal cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.
See more: Cloud differences in Juju
As the differences related to (1) are already documented generically in our Tutorial, How-to guides, and Reference docs, here we record just those that follow from (2).
This document describes details specific to using your existing Equinix Metal cloud with Juju.
See more: Equinix Metal
When using the Equinix Metal cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.
See more: Cloud differences in Juju
As the differences related to (1) are already documented generically in our Tutorial, How-to guides, and Reference docs, here we record just those that follow from (2).
| Juju points of variation | Notes for the Equinix Metal cloud |
|---|---|
| setup (chronological order): | |
| CLOUD | |
| requirements: | TBA |
| definition: | Already known to Juju. Run juju clouds --all to confirm. (Pre-defined cloud name in Juju: equinix.) |
| CREDENTIAL | |
| definition: |
auth-type: access-key <br> > See more: [Equinix Metal
|
| CONTROLLER | |
| notes on bootstrap: | – |
| other (alphabetical order:) | |
| CONFIGURATION (model) | |
| cloud-specific: | – |
| CONSTRAINT | |
| conflicting: | |
allocate-public-id |
TBA |
arch |
TBA |
container |
TBA |
cores |
TBA |
cpu-power |
TBA |
instance-role |
 |
instance-type |
TBA |
mem |
TBA |
root-disk |
TBA |
root-disk-source |
TBA |
spaces |
|
tags |
|
virt-type |
TBA |
zones |
TBA |
| PLACEMENT DIRECTIVE | |
<machine> |
TBA |
subnet=... |
|
system-id=... |
|
zone=... |
TBA |
|
RESOURCE (cloud) Consistent naming, tagging, and the ability to add user-controlled tags to created instances. |
|
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.