The detailed information about schema of an OpenStackDeployment (OsDpl)
custom resource can be obtained by running:
kubectl get crd openstackdeployments.lcm.mirantis.com -oyaml
The definition of a particular OpenStack deployment can be obtained by running:
kubectl -n openstack get osdpl -oyaml
apiVersion: lcm.mirantis.com/v1alpha1
kind: OpenStackDeployment
metadata:
name: openstack-cluster
namespace: openstack
spec:
openstack_version: train
preset: compute
size: tiny
internal_domain_name: cluster.local
public_domain_name: it.just.works
features:
ssl:
public_endpoints:
api_cert: |-
# Update server certificate content
api_key: |-
# Update server private key content
ca_cert: |-
# Update CA certificate content
neutron:
tunnel_interface: ens3
external_networks:
- physnet: physnet1
interface: veth-phy
bridge: br-ex
network_types:
- flat
vlan_ranges: null
mtu: null
floating_network:
enabled: False
nova:
live_migration_interface: ens3
images:
backend: local
For the detailed description of the OsDpl main elements, see the tables below:
Element |
Description |
|---|---|
|
Specifies the version of the Kubernetes API that is used to create this object. |
|
Specifies the kind of the object. |
|
Specifies the name of metadata. Should be set in compliance with the Kubernetes resource naming limitations. |
|
Specifies the metadata namespace. While technically it is possible to
deploy OpenStack on top of Kubernetes in other than Warning Both OpenStack and Kubernetes platforms provide resources to applications. When OpenStack is running on top of Kubernetes, Kubernetes is completely unaware of OpenStack-native workloads, such as virtual machines, for example. For better results and stability, Mirantis recommends using a dedicated Kubernetes cluster for OpenStack, so that OpenStack and auxiliary services, Ceph, and StackLight are the only Kubernetes applications running in the cluster. |
|
Contains the data that defines the OpenStack deployment and configuration. It has both high-level and low-level sections. The very basic values that must be provided include: spec:
openstack_version:
preset:
size:
internal_domain_name:
public_domain_name:
For the detailed description of the |
Element |
Description |
|---|---|
|
Specifies the OpenStack release to deploy. |
|
String that specifies the name of the
Every supported deployment profile incorporates an OpenStack preset. Refer to sup-profiles for the list of possible values. |
|
String that specifies the size category for the OpenStack cluster. The size category defines the internal configuration of the cluster such as the number of replicas for service workers and timeouts, etc. The list of supported sizes include:
|
|
Specifies the internal DNS name used inside the Kubernetes cluster on top of which the OpenStack cloud is deployed. |
|
Specifies the public DNS name for OpenStack services. This is a base DNS name that must be accessible and resolvable by API clients of your OpenStack cloud. It will be present in the OpenStack endpoints as presented by the OpenStack Identity service catalog. The TLS certificates used by the OpenStack services (see below) must also be issued to this DNS name. |
|
Contains the top-level collections of settings for the OpenStack deployment that potentially target several OpenStack services. The section where the customizations should take place. For example, for a minimal resource with the defined features, see the Example of an OsDpl CR of minimal configuration. |
|
Contains a list of extra OpenStack services to deploy. Extra OpenStack
services are services that are not included into |
|
Contains the content of SSL/TLS certificates (server, key, CA bundle) used to enable a secure communication to public OpenStack API services. These certificates must be issued to the DNS domain specified in the
|
|
Defines the name of the NIC device on the actual host that will be used for Neutron. We recommend setting up your Kubernetes hosts in such a way that networking is configured identically on all of them, and names of the interfaces serving the same purpose or plugged into the same network are consistent across all physical nodes. |
|
Defines the list of IPs of DNS servers that are accessible from virtual networks. Used as default DNS servers for VMs. |
|
Contains the data structure that defines external (provider) networks on top of which the Neutron networking will be created. |
|
If enabled, must contain the data structure defining the floating IP network that will be created for Neutron to provide external access to your Nova instances. |
|
Specifies the name of the NIC device on the actual host that will be used by Nova for the live migration of instances. We recommend setting up your Kubernetes hosts in such a way that networking is configured identically on all of them, and names of the interfaces serving the same purpose or plugged into the same network are consistent across all physical nodes. |
|
Specifies the object containing the Vault parameters to connect to Barbican. The list of supported options includes:
|
|
Defines the type of storage for Nova to use on the compute hosts for the images that back up the instances. The list of supported options include:
|
|
Defines parameters to connect to the Keycloak identity provider. |
|
Defines the domain-specific configuration and is useful for integration
with LDAP. An example of OsDpl with LDAP integration, which will create
a separate spec:
features:
keystone:
domain_specific_configuration:
enabled: true
domains:
- name: domain.with.ldap
config:
assignment:
driver: keystone.assignment.backends.sql.Assignment
identity:
driver: ldap
ldap:
chase_referrals: false
group_allow_create: false
group_allow_delete: false
group_allow_update: false
group_desc_attribute: description
group_id_attribute: cn
group_member_attribute: member
group_name_attribute: ou
group_objectclass: groupOfNames
page_size: 0
password: XXXXXXXXX
query_scope: sub
suffix: dc=mydomain,dc=com
url: ldap://ldap01.mydomain.com,ldap://ldap02.mydomain.com
user: uid=openstack,ou=people,o=mydomain,dc=com
user_allow_create: false
user_allow_delete: false
user_allow_update: false
user_enabled_attribute: enabled
user_enabled_default: false
user_enabled_invert: true
user_enabled_mask: 0
user_id_attribute: uid
user_mail_attribute: mail
user_name_attribute: uid
user_objectclass: inetOrgPerson
|
|
Specifies the Telemetry mode, which determines the permitted actions
for the Telemetry services. The only supported value is Caution To enable the Telemetry mode, the corresponding services
including the |
|
Specifies the standard logging levels for OpenStack services that
include the following, at increasing severity: spec:
features:
logging:
nova:
level: DEBUG
|
|
Defines the list of custom OpenStack Dashboard themes. Content of the archive file with a theme depends on the level of customization and can include static files, Django templates, and other artifacts. For the details, refer to OpenStack official documentation: Customizing Horizon Themes. spec:
features:
horizon:
themes:
- name: theme_name
description: The brand new theme
url: https://<path to .tgz file with the contents of custom theme>
sha256summ: <SHA256 checksum of the archive above>
|
|
A low-level section that defines the base URI prefixes for images and binary artifacts. |
|
A low-level section that defines values that will be passed to all
OpenStack ( Structure example: spec:
artifacts:
common:
openstack:
values:
infra:
values:
|
|
A section of the lowest level, enables the definition of specific values to pass to specific Helm charts on a one-by-one basis: |
Warning
Mirantis does not recommend changing the default settings for
spec:artifacts, spec:common, and spec:services elements.
Customizations can compromise the OpenStack deployment update and upgrade
processes.
Element |
Description |
|---|---|
|
Contains information about the current status of an OpenStack deployment, which cannot be changed by the user. |
|
Specifies the current status of Helm releases that are managed by the OpenStack Operator. The possible values include:
An example of children output: children:
openstack-block-storage: true
openstack-compute: true
openstack-coordination: true
...
|
|
Shows an overall status of all Helm releases. Shows |
|
Is the MD5 hash of the |
|
Contains the version of the OpenStack Operator that processes
the OsDpl resource. And, similarly to |
|
While
An example of the health output: health:
barbican:
api:
generation: 4
status: Ready
rabbitmq:
generation: 1
status: Ready
cinder:
api:
generation: 4
status: Ready
backup:
generation: 2
status: Ready
rabbitmq:
generation: 1
status: Ready
...
...
|
|
Contains the structure that is used by the Kopf library to store its internal data. |