OpenStackDeployment custom resource¶
The detailed information about schema of an OpenStackDeployment
custom resource can be obtained by running:
kubectl get crd openstackdeployments.lcm.mirantis.com -o yaml
The definition of a particular OpenStack deployment can be obtained by running:
kubectl -n openstack get osdpl -o yaml
apiVersion: lcm.mirantis.com/v1alpha1
kind: OpenStackDeployment
metadata:
name: openstack-cluster
namespace: openstack
spec:
openstack_version: victoria
preset: compute
size: tiny
internal_domain_name: cluster.local
public_domain_name: it.just.works
features:
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
Hiding sensitive information¶
Available since MOSK 23.1
The OpenStackDeployment custom resource enables you to securely store
sensitive fields in Kubernetes secrets. To do that, verify that the
reference secret is present in the same namespace as the
OpenStackDeployment object and the
openstack.lcm.mirantis.com/osdpl_secret label is set to true.
The list of fields that can be hidden from OpenStackDeployment is limited
and defined by the OpenStackDeployment schema.
For example, to hide spec:features:ssl:public_endpoints:api_cert, use the
following structure:
spec:
features:
ssl:
public_endpoints:
api_cert:
value_from:
secret_key_ref:
key: api_cert
name: osh-dev-hidden
Main elements¶
Element |
Sub-element |
Description |
|---|---|---|
|
n/a |
Specifies the version of the Kubernetes API that is used to create this object |
|
n/a |
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. |
|
|
|
Specifies the OpenStack release to deploy |
|
String that specifies the name of the
Every supported deployment profile incorporates an OpenStack preset. Refer to Deployment 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 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. |
|
|
Specifies the Kubernetes storage class name used for services to create
persistent volumes. For example, backups of MariaDB. If not specified,
the storage class marked as |
|
|
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. The |
region_name¶
TechPreview
The name of the region used for deployment, defaults to RegionOne.
features:policies¶
Defines the list of custom policies for OpenStack services.
Configuration structure:
spec:
features:
policies:
nova:
custom_policy: custom_value
The list of services available for configuration includes: Cinder, Nova, Designate, Keystone, Glance, Neutron, Heat, Octavia, Barbican, Placement, Ironic, aodh, Gnocchi, and Masakari.
Caution
Mirantis is not responsible for cloud operability in case of default policies modifications but provides API to pass the required configuration to the core OpenStack services.
features:policies:strict_admin¶
TechPreview
Enables a tested set of policies that limits the global admin role to
only the user with admin role in the admin project or user with the
service role. The latter should be used only for service users utilizied
for communication between OpenStack services.
Configuration structure:
spec:
features:
policies:
strict_admin:
enabled: true
services:
identity:
keystone:
values:
conf:
keystone:
resource:
admin_project_name: admin
admin_project_domain_name: Default
Note
The spec.services part of the above section will become
redundant in one of the following releases.
artifacts¶
A low-level section that defines the base URI prefixes for images and binary artifacts.
common¶
A low-level section that defines values that will be passed to all
OpenStack (spec:common:openstack) or auxiliary
(spec:common:infra) services Helm charts.
Configuration structure:
spec:
artifacts:
common:
openstack:
values:
infra:
values:
services¶
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.
However, you may need to edit the spec:services section to limit
hardware resources in case of a hyperconverged architecture as described in
Limit HW resources for hyperconverged OpenStack compute nodes.
Logging¶
Parameter |
|
|---|---|
Usage |
Specifies the standard logging levels for OpenStack services that
include the following, at increasing severity: Configuration example: spec:
features:
logging:
nova:
level: DEBUG
|
Node-specific configuration¶
Depending on the use case, you may need to configure the same application components differently on different hosts. MOSK enables you to easily perform the required configuration through node-specific overrides at the OpenStack Controller side.
The limitation of using the node-specific overrides is that they override only the configuration settings while other components, such as startup scripts and others, should be reconfigured as well.
Caution
The overrides have been implemented in a similar way to the OpenStack node and node label specific DaemonSet configurations. Though, the OpenStack Controller node-specific settings conflict with the upstream OpenStack node and node label specific DaemonSet configurations. Therefore, we do not recommend configuring node and node label overrides.
The list of allowed node labels is located in the Cluster object status
providerStatus.releaseRef.current.allowedNodeLabels field.
If the value field is not defined in allowedNodeLabels, a label can
have any value.
Before or after a machine deployment, add the required label from the allowed
node labels list with the corresponding value to
spec.providerSpec.value.nodeLabels in machine.yaml. For example:
nodeLabels:
- key: <NODE-LABEL>
value: <NODE-LABEL-VALUE>
The addition of a node label that is not available in the list of allowed node labels is restricted.
The node-specific settings are activated through the spec:nodes
section of the OsDpl CR. The spec:nodes section contains the following
subsections:
features- implements overrides for a limited subset of fields and is constructed similarly tospec::featuresservices- similarly tospec::services, enables you to override settings in general for the components running as DaemonSets.
Example configuration:
spec:
nodes:
<NODE-LABEL>::<NODE-LABEL-VALUE>:
features:
# Detailed information about features might be found at
# openstack_controller/admission/validators/nodes/schema.yaml
services:
<service>:
<chart>:
<chart_daemonset_name>:
values:
# Any value from specific helm chart
Tempest¶
Parameter |
|
|---|---|
Usage |
Enables tests against a deployed OpenStack cloud: spec:
features:
services:
- tempest
|
See also