OpenStack and Juju

system · 20 February 2019 12:31

List of supported clouds > OpenStack

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

See more: OpenStack

When using the OpenStack 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).

Supported cloud versions

Any version that supports:
- compute v2 (Nova)
- network v2 (Neutron) (optional)
- volume2 (Cinder) (optional)
- identity v2 or v3 (Keystone)

Notes on `juju add-cloud`

Type in Juju: openstack.

Name in Juju: User-defined.

If you want to use the novarc file (recommended):
Source the OpenStack RC file (source <path to file>). This will allow Juju to detect values from preset OpenStack environment variables. Run add-cloud in interactive mode and accept the suggested defaults.

Notes on `juju add-credential`

If you want to use environment variables (recommended):
Source the OpenStack RC file (see above). Run add-credential and accept the suggested defaults.

Authentication types

`userpass`

Attributes:

username: The username to authenticate with. (required)
password: The password for the specified username. (required)
tenant-name: The OpenStack tenant name. (optional)
tenant-id: The Openstack tenant ID (optional)
version: The Openstack identity version (optional)
domain-name: The OpenStack domain name. (optional)
project-domain-name: The OpenStack project domain name. (optional)
user-domain-name: The OpenStack user domain name. (optional)

Notes on `juju bootstrap`

You will need to create an OpenStack machine metadata. If the metadata is available locally, you can pass it to Juju via juju bootstrap ... --metadata-source <path to metadata simplestreams.
> See more: How to manage metadata

If your cloud has multiple private networks: You will need to specify the one that you want the instances to boot from via juju bootstrap ... --model-default network=<network uuid or name>.

If your cloud’s topology requires that its instances are accessed via floating IP addresses: Pass the allocate-public-ip=true (see constraints below) as a bootstrap constraint.

Cloud-specific model configuration keys

external-network

The network label or UUID to create floating IP addresses on when multiple external networks exist.


type	string
default value	“”
immutable	false
mandatory	false

use-openstack-gbp

Whether to use Neutrons Group-Based Policy


type	bool
default value	false
immutable	false
mandatory	false

policy-target-group

The UUID of Policy Target Group to use for Policy Targets created.


type	string
default value	“”
immutable	false
mandatory	false

use-default-secgroup

Whether new machine instances should have the “default” Openstack security group assigned in addition to juju defined security groups.


type	bool
default value	false
immutable	false
mandatory	false

network

The network label or UUID to bring machines up on when multiple networks exist.


type	string
default value	“”
immutable	false
mandatory	false

Supported constraints

Juju points of variation	Notes for the OpenStack cloud
CONSTRAINT
conflicting:	`[instance-type]` vs. `[mem, root-disk, cores]`
supported?
- `allocate-public-ip`
- `arch`
- `container`
- `cores`
- `cpu-power`
- `image-id`	(Starting with Juju 3.3) Type: String. Valid values: An OpenStack image ID.
- `instance-role`
- `instance-type`	Valid values: Any (cloud admin) user defined OpenStack flavor.
- `mem`
- `root-disk`
- `root-disk-source`	`root-disk-source` is either `local` or `volume`.
- `spaces`
- `tags`
- `virt-type`	Valid values: `[kvm, lxd]`.
- `zones`
PLACEMENT DIRECTIVE
`<machine>`	TBA
`subnet=...`
`system-id=...`
`zone=...`
MACHINE	–
RESOURCE (cloud) Consistent naming, tagging, and the ability to add user-controlled tags to created instances.

Contributors: @acsgn, @gerdner, @hallback, @tmihoc, @wallyworld

aurelien-lourot · 1 December 2019 20:55

We should tell people to do

juju bootstrap ... --model-default use-floating-ip=true

instead of

juju bootstrap ... --config use-floating-ip=true

because the latter only affects the default model, whereas the former will affect all models the user will create. See Configuring models. I personally wasted a lot of time because of this. I was creating my own model right after bootstrapping the controller and couldn’t understand why that option had no effect.

timClicks · 1 December 2019 21:23

Oh wow, I feel your pain. Thanks for taking the time to comment. I’ll update the recommendation. [Edit: I’ve made several changes to the document. Hopefully it’s easier to follow now.]

aurelien-lourot · 2 December 2019 08:48

@timClicks Thanks for the quick reaction! It’s actually --model-default, not --model-defaults (or do both work?). It’s easy to mix up with juju model-defaults which takes an ‘s’

timClicks · 2 December 2019 09:11

Fixed! Thanks for taking another look

nikolay.vinogradov · 20 August 2021 14:49

Perhaps "$ openstack network list " is missing here.

hmlanigan · 20 August 2021 18:07

Thank you! I’ve made the change.

pedroleaoc · 7 April 2022 09:24

pedroleaoc · 14 October 2022 11:31

gerdner · 9 September 2024 14:31

“access-key” seems to be a v2 auth method and is not supported since 2018. The only working auth-method for up to date openstack deployments is userpass. See Bug #1834433 “OpenStack Credentials: support Keystone applicatio...” : Bugs : Canonical Juju

tmihoc · 9 September 2024 15:00

Thanks for raising this – I’ll investigate!

PS At first glance, the access-key does still seem to be around: juju/provider/openstack/credentials.go at 3aec73a1c7bab405b04c0ff97eac042fda55f178 · juju/juju · GitHub I’ll see how those bugs impact its usability though – thanks again.

gerdner · 9 September 2024 15:03

Juju client uses goose under the hood. The access-key auth type will fall back to a v2 request see: goose/client/client.go at v5 · go-goose/goose · GitHub and will fail with a 404 not found (old v2 url) the error is missleading since v3 was specified in url and config but not used.

tmihoc · 9 September 2024 15:05

Thanks for the extra detail – I’ll definitely investigate!

wallyworld · 10 September 2024 06:10

access-key auth was done almost 10 years ago now back when Openstack offered an AWS compatibility shim. As stated above, my understanding is also that it’s no longer supported and it should be removed from the Juju code base.

gerdner · 10 September 2024 11:23

I don’t want to sound harsh, but this also means that juju currently does not support openstack clouds with external auth via saml/oidc like most public openstack clouds and most private openstack clouds. I mention this because this was a not expected limitation, I found out after debugging for hours. I guess this is not the right place to push this feature request, but it could help others looking for juju+openstack support to know about this limitation.

tmihoc · 10 September 2024 11:32

I’ll raise this with the developers. Thanks!

tmihoc · 12 September 2024 07:15

@gerdner Updated authentication types to exclude access-key (and added you to the list of contributors on the bottom of the doc – thanks for making me aware of the issue).

Also filed a bug to have related info removed from the codebase: Bug #2080203 “Juju codebase still shows OpenStack access-key eve...” : Bugs : Canonical Juju .

Also raised the issue of what this means for OpenStack clouds with external authentication via SAML/OIDC with the developers: Turns out this has been discussed before and there is indeed already a feature request to this effect. I’ve added your comment to the existing request to strengthen the case.

Thanks again!