[checked revision]

Latest revision as of 11:30, 23 March 2024

Abstract

This document describes the stoney cloud (OpenStack) relevant OpenLDAP directory data organisation.

Introduction

This document describes the OpenLDAP directory data organisation for the stoney cloud service.

Data Organisation

The following chapters explain the data organisation of the OpenStack based stoney cloud OpenLDAP directory, in this case we looking at the stoney cloud service.

OpenStack (service)

The sub tree ou=openstack,ou=service,dc=stoney-cloud,dc=org contains all the OpenStack based stoney cloud service data.

dn: ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: openstack

OpenStack (service) - Configuration

dn: ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: configuration
description: The sub tree for the configuration of the OpenStack based stoney cloud service.

OpenStack (service) - Configuration - Resellers

dn: ou=reseller,ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: reseller
description: The sub tree for the reseller specific configuration of the OpenStack based stoney cloud service.

OpenStack (service) - Domains (resellers)

dn: ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: domains
description: The sub tree for the domains (resellers) of the OpenStack based stoney cloud service.

OpenStack (service) - Domains (resellers) - Domain (OpenStack Default Domain) example

This is a very special domain and is created during the bootstrapping phase of the OpenStack installation. Therefore we never provision this domain and we do not add the objectclass: sstProvisioning to this domain.

dn: uid=3999998,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackDomain
objectclass: sstRelationship
uid: 3999999
sstOpenStackId: default
sstOpenStackName: Default
description: The default domain
sstIsActive: TRUE
sstIsIaaSDomain: FALSE
sstBillable: FALSE
sstConsolidatedBill: FALSE
sstRegion: duedingen_test
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

OpenStack (service) - Domains (resellers) - Domain (OpenStack Service Provider Domain) example

This is also quite a special domain, as it collects the cloud administrators of the OpenStack based stoney cloud. It is added manually just after the bootstrapping phase. Therefore we never provision this domain and we do not add the objectclass: sstProvisioning to this domain.

dn: uid=3999999,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackDomain
objectclass: sstRelationship
uid: 3999999
sstOpenStackId: abcdef2477be64c099500224864999998
sstOpenStackName: Service Provider
description: Service Provider stepping stone AG
sstIsActive: TRUE
sstIsIaaSDomain: FALSE
sstBillable: FALSE
sstConsolidatedBill: FALSE
sstRegion: duedingen_test
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

OpenStack (service) - Domains (resellers) - Domain (reseller) example

The following LDIF example shows a typical OpenStack Domain.

dn: uid=4000000,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackDomain
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 4000000
sstOpenStackId: b01822477be64c09950022486300c59c
sstOpenStackName: Reseller Ltd.
description: 4000000 - Reseller Ltd.
sstIsActive: TRUE
sstIsIaaSDomain: FALSE
sstBillable: TRUE
sstNonBillableItem: network_id:f7f865e8-a745-455c-80cf-b0a4ea09323c
sstCancellationDate: 20201231
sstConsolidatedBill: FALSE
sstRegion: duedingen_test
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

The following table describes the different attributes:

Attribute	Objectclass	Existence	Mandatory	Description
uid	sstOpenStackDomain	MUST	x	A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of `uid` corresponds with the value of `sstBelongsToResellerUID`. For example: `uid: 4000000` corresponds with `sstBelongsToResellerUID: 4000000`.
sstOpenStackId	sstOpenStackDomain	MAY	x³	The OpenStack Domain id as returned from the OpenStack API. For example: `"id" : "b01822477be64c09950022486300c59c"`. This gives us the LDAP entry: `sstOpenStackId: b01822477be64c09950022486300c59c`.
sstOpenStackName	sstOpenStackDomain	MAY	x	The OpenStack Domain name as returned from the OpenStack API. For example: `"name" : "Reseller Ltd."`. This gives us the LDAP entry: `sstOpenStackName: Reseller Ltd.`.
description	sstOpenStackDomain	MAY	x	The description is built up as follows: `<sstBelongsToResellerUID> - <sstOpenStackName>`. For example: `description: 4000000 - Reseller Ltd.`.
sstIsActive	sstOpenStackDomain	MUST	x	Is the entry active? Either `TRUE` (yes) or `FALSE` (no). The default value is `TRUE`.
sstIsIaaSDomain	sstOpenStackDomain	MAY	x	Is the OpenStack based Domain (reseller) a Infrastructure as a Service (IaaS) Domain? Either yes (TRUE) or no (FALSE). The default value is `FALSE`.
sstBillable	sstOpenStackDomain	MAY	x	It the entry billable? Either `TRUE` (yes) or `FALSE` (no). All hierarchical levels must have `sstBillable: TRUE` to actually have an invoice generated and sent. If the attribute `sstBillable` doesn't exist, the default is `TRUE`. This way, we are forced to set a reseller, customer or product manually to `sstBillable: FALSE` if we want to avoid sending them an invoice.
sstNonBillableItem	sstRelationship	MAY		This multi-valued attribute lists the items, that aren't billable, even if `sstBillable` is set to `TRUE`. The following example presumes, that the reseller with `sstBelongsToResellerUID: 4000000` has their own floating ip range with the OpenStack with the `network_id` `f7f865e8-a745-455c-80cf-b0a4ea09323c`. Example: `sstNonBillableItem: network_id:f7f865e8-a745-455c-80cf-b0a4ea09323c`
sstCancellationDate	sstOpenStackDomain	MAY		The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231. The attribute `sstCancellationDate` is used in a logical AND combination with `sstIsActive`. With other words: Once the cancellation date has passed, it overrides the `sstIsActive` value.
sstConsolidatedBill	sstOpenStackDomain	MAY	x	Do we want to have a consolidated bill for the OpenStack Domain? Either yes (TRUE) or no (FALSE). The default value is `FALSE`.
sstRegion	sstOpenStackDomain	MAY	x	The region tells us, were the infrastructure (domains, projects, networks, servers and more) is to be provisioned. Currently duedingen_production and duedingen_test are supported. The default region is duedingen_production. The default value is `duedingen_production`.
sstProvisioningMode	sstProvisioning	MUST	x¹	The provisioning mode, either `add`, `modify` or `delete`. For a new account, this attribute must be set to `add`. See the stoney core: OpenLDAP provisioning page for details. If the entry was successfully added, modified or deleted, the provisioning mode is changed to `added`, `modified` or `deleted`.
sstProvisioningExecutionDate	sstProvisioning	MUST	x	The date the provisioning shall occur in the form of [YYYY][MM][DD] (ISO 8601). For a new account, this attribute must be set to 0. See the stoney core: OpenLDAP provisioning page for details.
sstProvisioningState	sstProvisioning	MUST	x²	The provisioning state, either `0` or in the form of `[YYYY][MM][DD]T[hh][mm][ss]Z` (ISO 8601). Z is the zone designator for the zero UTC offset. For a new OpenStack Domain, this attribute must be set to 0. After the successful provisioning, the value is set to the time of the provisioning. For example: `sstProvisioningState: 20180819T083208Z`. See the stoney core: OpenLDAP provisioning page for details.
sstBelongsToResellerUID	sstRelationship	MAY	x	Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of `sstBelongsToResellerUID` corresponds with the value of `uid`. For example: `sstBelongsToResellerUID: 4000000` corresponds with `uid: 4000000`.
sstBelongsToCustomerUID	sstRelationship	MAY	x	Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute `sstBelongsToCustomerUID` should always be set to the customer UID, that reflects the reseller for the OpenStack Domains. For example: `sstBelongsToCustomerUID: 4000001`.

Legend:

x: Mandatory in all cases.
x¹: Set sstProvisioningMode to either added, modified or deleted if modifying the entry manually.
x²: Use date --utc "+%Y%m%dT%H%M%SZ" to set the attribute sstProvisioningState if modifying the entry manually.
x³: Set by Terraform after the successful provisioning.

OpenStack (service) - Projects (tenants)

dn: ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: projects
description: The sub tree for the projects (tenants) of the OpenStack based stoney cloud service.

OpenStack (service) - Projects (tenants) - Examples

Due to the OpenStack project (tenant) organisation, we can have multiple tenants per domain (reseller) and customers. The following LDIF example show the first project of the customer Customer Ltd. with the sstBelongsToCustomerUID: 4000001 belonging to the reseller Reseller Ltd. with the sstBelongsToResellerUID: 4000000:

dn: uid=4100000,ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackProject
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 4100000
sstOpenStackId: 5a3a4fd5d6e94a87815131be42d8e6d9
sstOpenStackName: Customer Ltd. - Internal Systems
description: 4000000/4000001 - Customer Ltd. - Internal Systems
sstNetworkHostnameFormat: cur-int-%03d
sstNetworkHostnameNextFreeNumber: 1
sstIsActive: TRUE
sstIsIaaSProject: FALSE
sstBillable: TRUE
sstCancellationDate: 20201231
sstConsolidatedBill: FALSE
sstRegion: duedingen_test
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

Please visit the Account Naming page and the Customer VM Naming Convention for the sstNetworkHostnameFormat.

The following LDIF example show the second project of the customer Customer Ltd. with the sstBelongsToCustomerUID: 4000001 belonging to the reseller Reseller Ltd. with the sstBelongsToResellerUID: 4000000:

dn: uid=4100001,ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackProject
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 4100001
sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstOpenStackName: Customer Ltd. - Public Systems
description: 4000000/4000001 - Customer Ltd. - Public Systems
sstNetworkHostnameFormat: cur-pub-%03d
sstNetworkHostnameNextFreeNumber: 1
sstIsActive: TRUE
sstIsIaaSProject: FALSE
sstBillable: TRUE
sstConsolidatedBill: FALSE
sstRegion: duedingen_test
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

Please visit the Account Naming page and the Customer VM Naming Convention for the sstNetworkHostnameFormat.

The following table describes the different attributes:

Attribute	Objectclass	Existence	Mandatory	Description
uid	sstOpenStackProject	MUST	x	A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of `uid` corresponds with the value of `sstBelongsToResellerUID`. For example: `uid: 4000000` corresponds with `sstBelongsToResellerUID: 4000000`.
sstOpenStackId	sstOpenStackProject	MAY	x	The OpenStack project id as returned from the OpenStack API. For example: `"id" : "5a3a4fd5d6e94a87815131be42d8e6d9"`. This gives us the LDAP entry: `sstOpenStackId: 5a3a4fd5d6e94a87815131be42d8e6d9`.
sstOpenStackName	sstOpenStackProject	MAY	x	The OpenStack project name as returned from the OpenStack API. For example: `"name" : "Customer Ltd. - Public Systems"`. This gives us the LDAP entry: `sstOpenStackName: Customer Ltd. - Public Systems`.
description	sstOpenStackProject	MAY	x	The description is built up as follows: `<sstBelongsToResellerUID>/<sstBelongsToCustomerUID> - <sstOpenStackName>`. For example: `4000000/4000001 - Customer Ltd. - Public Systems`.
sstNetworkHostnameFormat	sstOpenStackProject	MAY	x¹	If `sstIsIaaSProject` is set to `FALSE`, it must be set manually. If `sstIsIaaSProject` is set to `TRUE`, this attribute must not be set (is not allowed). For example: `sstNetworkHostnameFormat: cur-int-%03d`. The value of `sstNetworkHostnameFormat` is set manually and is derived from the value of `sstOpenStackName` according to the rules defined in Account Naming and Customer VM Naming Convention.
sstNetworkHostnameNextFreeNumber	sstOpenStackProject	MAY	x²	If `sstIsIaaSProject` is set to `FALSE`, it must be set manually. If `sstIsIaaSProject` is set to `TRUE`, this attribute must not be set (is not allowed). For example: `sstNetworkHostnameNextFreeNumber: 1`. Where `1` is the default for a new project.
sstIsActive	sstOpenStackProject	MUST	x	Is the entry active? Either `TRUE` (yes) or `FALSE` (no). The default value is `TRUE`.
sstIsIaaSProject	sstOpenStackProject	MAY	x	Is the OpenStack based Project (tenant) a Infrastructure as a Service (IaaS) Project? Either yes (TRUE) or no (FALSE). The default value is `FALSE`.
sstBillable	sstOpenStackProject	MAY	x	It the entry billable? Either `TRUE` (yes) or `FALSE` (no). All hierarchical levels must have `sstBillable: TRUE` to actually have an invoice generated and sent. If the attribute `sstBillable` doesn't exist, the default is `TRUE`. This way, we are forced to set a reseller, customer or product manually to `sstBillable: FALSE` if we want to avoid sending them an invoice.
sstCancellationDate	sstOpenStackProject	MAY		The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231. The attribute `sstCancellationDate` is used in a logical AND combination with `sstIsActive`. With other words: Once the cancellation date has passed, it overrides the `sstIsActive` value.
sstConsolidatedBill	sstOpenStackProject	MAY	x	Do we want to have a consolidated bill for the OpenStack Project? Either yes (TRUE) or no (FALSE). The default value is `FALSE`.
sstRegion	sstOpenStackProject	MAY	x	The region tells us, were the infrastructure (domains, projects, networks, servers and more) is to be provisioned. Currently duedingen_production and duedingen_test are supported. The default region is duedingen_production. The default value is `duedingen_production`.
sstProvisioningMode	sstProvisioning	MUST	x³	The provisioning mode, either `add`, `modify` or `delete`. For a new account, this attribute must be set to `add`. See the stoney core: OpenLDAP provisioning page for details. If the entry was successfully added, modified or deleted, the provisioning mode is changed to `added`, `modified` or `deleted`.
sstProvisioningExecutionDate	sstProvisioning	MUST	x	The date the provisioning shall occur in the form of [YYYY][MM][DD] (ISO 8601). For a new account, this attribute must be set to 0. See the stoney core: OpenLDAP provisioning page for details.
sstProvisioningState	sstProvisioning	MUST	x⁴	The provisioning state, either `0` or in the form of `[YYYY][MM][DD]T[hh][mm][ss]Z` (ISO 8601). Z is the zone designator for the zero UTC offset. For a new OpenStack Project, this attribute must be set to 0. After the successful provisioning, the value is set to the time of the provisioning. For example: `sstProvisioningState: 20180819T083208Z`. See the stoney core: OpenLDAP provisioning page for details.
sstBelongsToDomainID	sstOpenStackProject	MAY	x⁵	The OpenStack domain id the project belongs to. For example: `sstBelongsToDomainID: b01822477be64c09950022486300c59c`.
sstBelongsToResellerUID	sstRelationship	<center>MAY	x	Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of `sstBelongsToResellerUID` corresponds with the value of `uid`. For example: `sstBelongsToResellerUID: 4000000` corresponds with `uid: 4000000`.
sstBelongsToCustomerUID	sstRelationship	MAY	x	Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute `sstBelongsToCustomerUID` should always be set to the customer UID, that reflects the reseller for the OpenStack Domains. For example: `sstBelongsToCustomerUID: 4000001`.

Legend:

x: Mandatory in all cases.
x¹: If sstIsIaaSProject is set to FALSE, the attribute sstNetworkHostnameFormat must be set manually. If sstIsIaaSProject is set to TRUE, the attribute sstNetworkHostnameFormat must not be set (is not allowed).
x²: If sstIsIaaSProject is set to FALSE, the attribute sstNetworkHostnameNextFreeNumber it must be set manually. If sstIsIaaSProject is set to TRUE, the attribute sstNetworkHostnameNextFreeNumber must not be set (is not allowed).
x³: Set sstProvisioningMode to either added, modified or deleted if modifying the entry manually.
x⁴: Use date --utc "+%Y%m%dT%H%M%SZ" to set the attribute sstProvisioningState if modifying the entry manually.
x⁵: The attribute sstBelongsToDomainID is optional, as it will be set during the provisioning of the OpenStack project via OpenTofu (Terraform).

OpenStack (service) - Units (instances)

dn: ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: projects
description: The sub tree for the units (instances) of the OpenStack based stoney cloud service.

OpenStack (service) - Units (instances) - Examples

dn: uid=4100002,ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackUnit
objectclass: sstProvisioning
objectclass: sstRelationship
objectclass: sstConfigurationManagement
uid: 4100002
sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)
description: The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).
sstOperatingSystem: Linux
sstNetworkHostname: sst-int-001
sstNetworkDomainName: os.stoney-cloud.com
sstIsActive: TRUE
sstBillable: TRUE
sstCancellationDate: 20201231
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBusinessLogicRoleName: erp_odoo
sstRegion: duedingen_production
sstEnvironment: production
sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

Please visit the Account Naming page and the Customer VM Naming Convention for the sstNetworkHostnameFormat.

The following table describes the different attributes:

Attribute	Objectclass	Existence	Mandatory	Description
uid	sstOpenStackUnit	MUST	x	A unique integer value with 7 digits or more. For example: `uid: 4100002`.
sstOpenStackId	sstOpenStackUnit	MAY	x¹	The OpenStack unit id as returned from the OpenStack API. For example: `"id" : "9ecb5bfdd4564f6ca52bba1e869eeea4"`. This gives us the LDAP entry: `sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4`.
sstDisplayName	sstOpenStackUnit	MUST	x	The human readable display name. For example: `"name" : "description"`. This gives us the LDAP entry: `sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)`.
description	sstOpenStackUnit	MAY	x	The description is built up as follows: `The leaf for the OpenStack server <sstDisplayName>.`. For example: `The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).`.
sstOperatingSystem	sstOpenStackUnit	MAY		A manually executed maintenance window for Windows systems is significantly more time-consuming than for Linux. Therefore we need to know the operating system. Possible values are `sstOperatingSystem: Linux` `sstOperatingSystem: Windows`. This attribute is only relevant, if `sstServiceAutomated` is set to `FALSE` (under `ou=units,ou=maintenance,ou=services,dc=stoney-cloud,dc=org`). See the Maintenance units documentation.
sstNetworkHostname	sstOpenStackUnit	MUST	x	The host name of the unit according to the rules defined in Account Naming and Customer VM Naming Convention. For example: `sst-int-001`.
sstNetworkDomainName	sstOpenStackUnit	MUST	x	The domain name of the unit. For example: `os.stoney-cloud.com`.
sstIsActive	sstOpenStackUnit	MUST	x	Is the entry active? Either `TRUE` (yes) or `FALSE` (no). The default value is `TRUE`.
sstBillable	sstOpenStackUnit	MAY	x	It the entry billable? Either `TRUE` (yes) or `FALSE` (no). All hierarchical levels must have `sstBillable: TRUE` to actually have an invoice generated and sent. If the attribute `sstBillable` doesn't exist, the default is `TRUE`. This way, we are forced to set a reseller, customer or product manually to `sstBillable: FALSE` if we want to avoid sending them an invoice.
sstCancellationDate	sstOpenStackUnit	MAY		The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231. The attribute `sstCancellationDate` is used in a logical AND combination with `sstIsActive`. With other words: Once the cancellation date has passed, it overrides the `sstIsActive` value.
sstProvisioningMode	sstProvisioning	MUST	x²	The provisioning mode, either `add`, `modify` or `delete`. For a new account, this attribute must be set to `add`. See the stoney core: OpenLDAP provisioning page for details. If the entry was successfully added, modified or deleted, the provisioning mode is changed to `added`, `modified` or `deleted`.
sstProvisioningExecutionDate	sstProvisioning	MUST	x	The date the provisioning shall occur in the form of [YYYY][MM][DD] (ISO 8601). For a new account, this attribute must be set to 0. See the stoney core: OpenLDAP provisioning page for details.
sstProvisioningState	sstProvisioning	MUST	x³	The provisioning state, either `0` or in the form of `[YYYY][MM][DD]T[hh][mm][ss]Z` (ISO 8601). Z is the zone designator for the zero UTC offset. For a new OpenStack Unit, this attribute must be set to 0. After the successful provisioning, the value is set to the time of the provisioning. For example: `sstProvisioningState: 20180819T083208Z`. See the stoney core: OpenLDAP provisioning page for details.
sstBusinessLogicRoleName	sstConfigurationManagement	MUST	x	The Puppet role (business logic). For example: `sstBusinessLogicRoleName: erp_odoo`.
sstRegion	sstConfigurationManagement	MAY	x	The geographical region. For example: `sstRegion: duedingen_production` or `sstRegion: cn_azure_china_east_2`.
sstEnvironment	sstConfigurationManagement	MAY	x	The Puppet environment. For example: `sstEnvironment: production`, `sstEnvironment: integration`, `sstEnvironment: test` or individual feature branches.
sstBelongsToProjectID	sstOpenStackUnit	MUST	x	The OpenStack project id the project belongs to. For example: `sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9`.
sstBelongsToResellerUID	sstRelationship	MAY	x	Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. For example: `sstBelongsToResellerUID: 4000000`.
sstBelongsToCustomerUID	sstRelationship	MAY	x	Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute `sstBelongsToCustomerUID` should always be set to the customer UID, that reflects the reseller for the OpenStack Domains. For example: `sstBelongsToCustomerUID: 4000001`.

Legend:

x: Mandatory in all cases.
x¹: Must be set after the provisioning, as OpenStack doesn't allow to set ids.
x²: Set sstProvisioningMode to either added, modified or deleted if modifying the entry manually.
x³: Use date --utc "+%Y%m%dT%H%M%SZ" to set the attribute sstProvisioningState if modifying the entry manually.

OpenStack (service) - Image backups

dn: ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: backups
description: The sub tree for the image backups of the units (instances) in the OpenStack based stoney cloud service.

OpenStack (service) - Image backups - Examples

dn: uid=4100004,ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackImageBackup
objectclass: sstRelationship
uid: 4100004
sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)
description: The leaf for the image backup of the OpenStack instance 'sst-int-001: stepping stone AG: CentOS 7 (Odoo)'.
sstBackupIterations: 1
sstBackupLastSuccessfulBackup: computer:20130923T063554Z
sstIsActive: TRUE
sstBillable: TRUE
sstCancellationDate: 20201231
sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9
sstBelongsToUnitID: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToServiceUID: 4000002

Please visit the Account Naming page and the Customer VM Naming Convention for the sstNetworkHostnameFormat.

The following table describes the different attributes:

Attribute	Objectclass	Existence	Mandatory	Description
uid	sstOpenStackImageBackup	MUST	x	A unique integer value with 7 digits or more. For example: `uid: 4100002`.
sstDisplayName	sstOpenStackImageBackup	MUST	x	The OpenStack project name as returned from the OpenStack API. For example: `"name" : "sst-int-001: stepping stone AG: CentOS 7 (Odoo)"`. This gives us the LDAP entry: `sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)`.
description	sstOpenStackImageBackup	MAY	x	The description is built up as follows: `The leaf for the OpenStack server <sstDisplayName>.`. For example: `The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).`.
sstBackupIterations	sstOpenStackImageBackup	MUST	x	The number of image backup iterations. Possible values are between 0 and 9999. Default is `1`. For example: `sstBackupIterations: 1`.
sstBackupLastSuccessfulBackup	sstOpenStackImageBackup	MAY		The date and time of the last successful image backup in UTC, either 0 or in the form of `[YYYY][MM][DD]T[hh][mm][ss]Z` (ISO 8601). For example: `sstBackupLastSuccessfulBackup: 20130923T063554Z`.
sstIsActive	sstOpenStackImageBackup	MUST	x	Is the entry active? Either `TRUE` (yes) or `FALSE` (no). The default value is `TRUE`.
sstBillable	sstOpenStackImageBackup	MAY	x	It the entry billable? Either `TRUE` (yes) or `FALSE` (no). All hierarchical levels must have `sstBillable: TRUE` to actually have an invoice generated and sent. If the attribute `sstBillable` doesn't exist, the default is `TRUE`. This way, we are forced to set a reseller, customer or product manually to `sstBillable: FALSE` if we want to avoid sending them an invoice.
sstCancellationDate	sstOpenStackImageBackup	MAY		The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: `sstCancellationDate: 20201231`. The attribute `sstCancellationDate` is used in a logical AND combination with `sstIsActive`. With other words: Once the cancellation date has passed, it overrides the `sstIsActive` value.
sstBelongsToProjectID	sstOpenStackImageBackup	MUST	x	The OpenStack project id the project belongs to. For example: `sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9`.
sstBelongsToUnitID	sstOpenStackImageBackup	MAY	x¹	The OpenStack unit id as returned from the OpenStack API. For example: `sstBelongsToUnitID: 9ecb5bfdd4564f6ca52bba1e869eeea4`.
sstBelongsToResellerUID	sstRelationship	MAY	x	Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. For example: `sstBelongsToResellerUID: 4000000`.
sstBelongsToCustomerUID	sstRelationship	MAY	x	Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute `sstBelongsToCustomerUID` should always be set to the customer UID, that reflects the reseller for the OpenStack Domains. For example: `sstBelongsToCustomerUID: 4000001`.
sstBelongsToServiceUID	sstRelationship	MAY	x	Stores the UID (Unique Identifier) of the service the leaf belongs to. This UID can be used to look up other information. For example, if the attribute sstBelongsToUnitID is missing, we can look this value up (and maybe update it at the same time to spare future lookups). For example: `sstBelongsToServiceUID: 4000002`.

Legend:

x: Mandatory in all cases.
x¹: Must be set after the provisioning, as OpenStack doesn't allow to set ids.

OpenStack (service) - Licences (...)

Is a main service, not a sub service of the openstack service.

dn: ou=licences,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: projects
description: The sub tree for the ...

OpenStack (service) - Licences (...) - Examples

...

dn: uid=1234567,ou=licences,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackUnit
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 1234567
description: Bla, bla ...
sstIsActive: TRUE
sstBillable: TRUE
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002 <- Either this or sstBelongsToServiceUID
sstBelongsToServiceUID <- What value? Will this cause a ldap search over all the services?

OpenStack (infrastructure)

The sub tree ou=dedicated servers,ou=service,dc=stoney-cloud,dc=org contains all the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs) information.

dn: ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
description: This sub tree contains all the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs) information.
ou: openstack

OpenStack (infrastructure) - Configuration

dn: ou=configuration,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: configuration
description: The sub tree for the configuration of all the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs).

OpenStack (infrastructure) - Configuration - Resellers

dn: ou=reseller,ou=configuration,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: reseller
description: The sub tree for the reseller specific configuration of the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs).

OpenStack (infrastructure) - Units (control-, compute- and storage-nodes as well as the control virtual machines)

dn: ou=units,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org 
objectclass: top
objectclass: organizationalUnit
ou: units
description: The sub tree for the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs), called units.

OpenStack (infrastructure) - Unit (control-, compute- and storage-nodes as well as the control virtual machines) - Examples

Some concrete naming examples of the OpenStack control-, compute- and storage nodes as well as the control virtual machines (VMs):

Control nodes:

ctrl-node-001: stepping stone AG: CentOS 7 (Control), with the Puppet role cloud_openstack_control
ctrl-node-002: stepping stone AG: CentOS 7 (Control), with the Puppet role cloud_openstack_control

Compute nodes:

compute-node-001: stepping stone AG: CentOS 7 (Compute), with the Puppet role cloud_openstack_compute
compute-node-002: stepping stone AG: CentOS 7 (Compute), with the Puppet role cloud_openstack_compute

Storage nodes:

storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor), with the Puppet role storage_ceph
storage-node-002: stepping stone AG: CentOS 7 (Ceph monitor), with the Puppet role storage_ceph
storage-node-003: stepping stone AG: CentOS 7 (Ceph storage), with the Puppet role storage_ceph

Control VMs:

ctrl-vm-020: stepping stone AG: CentOS 7 (Ceph monitor), with the Puppet role storage_ceph
ctrl-vm-021: stepping stone AG: CentOS 7 (Glance), with the Puppet role cloud_openstack_glance

The following LDIF shows a complete example of storage node with the Puppet role storage_ceph.

dn: uid=4100002,ou=units,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstServer
objectclass: sstRelationship
objectclass: sstConfigurationManagement
uid: 4100002
sstDisplayName: storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor)
description: The leaf for the OpenStack infrastructure server storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor).
sstNetworkHostname: storage-node-001
sstNetworkDomainName: ctrl-int.os.stoney-cloud.com
sstIsActive: TRUE
sstBillable: FALSE
sstBusinessLogicRoleName: storage_ceph
sstRegion: duedingen_production
sstEnvironment: production
sstBelongsToProjectID: 6907bf36283fee21f1396b803d041041
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

Please visit the Account Naming page and the Customer VM Naming Convention for the sstNetworkHostnameFormat.

The following table describes the different attributes:

Attribute	Objectclass	Existence	Mandatory	Description
uid	sstServer	MUST	x	A unique integer value with 7 digits or more. For example: `uid: 4100002`.
sstDisplayName	sstServer	MUST	x	The human readable display name. For example: `"name" : "description"`. This gives us the LDAP entry: `sstDisplayName: storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor)`.
description	sstServer	MAY	x	The description is built up as follows: `The leaf for the OpenStack server <sstDisplayName>.`. For example: `The leaf for the OpenStack server storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor).`.
sstOperatingSystem	sstServer	MAY		A manually executed maintenance window for Windows systems is significantly more time-consuming than for Linux. Therefore we need to know the operating system. Possible values are `sstOperatingSystem: Linux` `sstOperatingSystem: Windows`. This attribute is only relevant, if `sstServiceAutomated` is set to `FALSE` (under `ou=units,ou=maintenance,ou=services,dc=stoney-cloud,dc=org`). See the Maintenance units documentation.
sstNetworkHostname	sstServer	MUST	x	The host name of the unit according to the rules defined in Account Naming and Customer VM Naming Convention. For example: `sst-int-001`.
sstNetworkDomainName	sstServer	MUST	x	The domain name of the unit. For example: `ctrl-int.os.stoney-cloud.com`.
sstIsActive	sstRelationship	MAY	x	Is the entry active? Either `TRUE` (yes) or `FALSE` (no). The default value is `TRUE`.
sstBillable	sstRelationship	MAY	x	It the entry billable? Either `TRUE` (yes) or `FALSE` (no). All hierarchical levels must have `sstBillable: TRUE` to actually have an invoice generated and sent. If the attribute `sstBillable` doesn't exist, the default is `TRUE`. This way, we are forced to set a reseller, customer or product manually to `sstBillable: FALSE` if we want to avoid sending them an invoice.
sstCancellationDate	sstRelationship	MAY		The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231. The attribute `sstCancellationDate` is used in a logical AND combination with `sstIsActive`. With other words: Once the cancellation date has passed, it overrides the `sstIsActive` value.
sstBusinessLogicRoleName	sstConfigurationManagement	MUST	x	The Puppet role (business logic). For example: `sstBusinessLogicRoleName: storage_ceph`.
sstRegion	sstConfigurationManagement	MAY	x	The geographical region. For example: `sstRegion: duedingen_production` or `sstRegion: cn_azure_china_east_2`.
sstEnvironment	sstConfigurationManagement	MAY	x	The Puppet environment. For example: `sstEnvironment: production`, `sstEnvironment: integration`, `sstEnvironment: test` or individual feature branches.
sstBelongsToProjectID	sstServer	MAY		The (virtual) OpenStack project id the project belongs to. The project id used by the configuration management system Puppet via enc. For example: `6907bf36283fee21f1396b803d041041`.
sstBelongsToResellerUID	sstRelationship	MAY	x	Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. For example: `sstBelongsToResellerUID: 4000000`.
sstBelongsToCustomerUID	sstRelationship	MAY	x	Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute `sstBelongsToCustomerUID` should always be set to the customer UID, that reflects the reseller for the OpenStack Domains. For example: `sstBelongsToCustomerUID: 4000001`.

Legend:

x: Mandatory in all cases.

Questions

We need a mechanism to make sure, that the internal OpenStack domain(s) and the corresponding project(s) don't get provisioned!
Should we have a configuraton sub tree with sane default values?
Should we store the current values in the LDAP (CPU, RAM, ...)?
Will we store the network configuraton in the LDAP?
- If yes, how will we store the additional networks in the LDAP (shared network)?
How will we make sure, not to bill the IPv4 netwoks, belonging to a reseller and/or customer?
- For example Fence IT AG?
Will we have both sstBelongsToDomainID and sstBelongsToDomainUID or just one or the other?

Difference between revisions of "stoney cloud: OpenLDAP directory data organisation"

Latest revision as of 11:30, 23 March 2024

Contents

Abstract

Introduction

Data Organisation

OpenStack (service)

OpenStack (service) - Configuration

OpenStack (service) - Configuration - Resellers

OpenStack (service) - Domains (resellers)

OpenStack (service) - Domains (resellers) - Domain (OpenStack Default Domain) example

OpenStack (service) - Domains (resellers) - Domain (OpenStack Service Provider Domain) example

OpenStack (service) - Domains (resellers) - Domain (reseller) example

OpenStack (service) - Projects (tenants)

OpenStack (service) - Projects (tenants) - Examples

OpenStack (service) - Units (instances)

OpenStack (service) - Units (instances) - Examples

OpenStack (service) - Image backups

OpenStack (service) - Image backups - Examples

OpenStack (service) - Licences (...)

OpenStack (service) - Licences (...) - Examples

OpenStack (infrastructure)

OpenStack (infrastructure) - Configuration

OpenStack (infrastructure) - Configuration - Resellers

OpenStack (infrastructure) - Units (control-, compute- and storage-nodes as well as the control virtual machines)

OpenStack (infrastructure) - Unit (control-, compute- and storage-nodes as well as the control virtual machines) - Examples

Questions

Navigation menu

Personal tools

Namespaces

Variants

Views

Actions

Search

Navigation

Wiki

Tools

@@ Line 6: / Line 6: @@
 = Data Organisation =
-The following chapters explain the data organisation of the stoney cloud OpenLDAP directory, in this case we looking at the [https://www.stoney-cloud.com/ stoney cloud] service.
+The following chapters explain the data organisation of the [https://www.openstack.org/ OpenStack] based stoney cloud OpenLDAP directory, in this case we looking at the [https://www.stoney-cloud.com/ stoney cloud] service.
-== IaaS (Infrastructure as a Service) ==
+== OpenStack (service) ==
-The sub tree <code>ou=openstack,ou=service,dc=stoney-cloud,dc=org</code> contains all the OpenStack based stoney cloud service data. The following LDIF shows the '''iaas''' LDAP entry for the stoney cloud service:
+The sub tree <code>ou=openstack,ou=service,dc=stoney-cloud,dc=org</code> contains all the OpenStack based stoney cloud service data.
 <source lang="ldif">
 dn: ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 17: / Line 17: @@
 </source>
-=== Configuration ===
+=== OpenStack (service) - Configuration ===
 <source lang="ldif">
 dn: ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 26: / Line 26: @@
 </source>
-==== Configuration (resellers) ====
+==== OpenStack (service) - Configuration - Resellers ====
 <source lang="ldif">
 dn: ou=reseller,ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 35: / Line 35: @@
 </source>
-=== Domains (resellers) ===
+=== OpenStack (service) - Domains (resellers) ===
 <source lang="ldif">
 dn: ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 44: / Line 44: @@
 </source>
-==== Domain (OpenStack Default Domain) example ====
+==== OpenStack (service) - Domains (resellers) - Domain (OpenStack Default Domain) example ====
 This is a very special domain and is created during the bootstrapping phase of the OpenStack installation. Therefore we '''never''' provision this domain and we '''do not''' add the <code>objectclass: sstProvisioning</code> to this domain.
 <source lang="ldif">
@@ Line 59: / Line 59: @@
 sstBillable: FALSE
 sstConsolidatedBill: FALSE
+sstRegion: duedingen_test
 sstBelongsToResellerUID: 4000000
 sstBelongsToCustomerUID: 4000001
 </source>
-==== Domain (OpenStack Service Provider Domain) example ====
+==== OpenStack (service) - Domains (resellers) - Domain (OpenStack Service Provider Domain) example ====
 This is also quite a special domain, as it collects the cloud administrators of the OpenStack based stoney cloud. It is added manually just after the bootstrapping phase. Therefore we '''never''' provision this domain and we '''do not''' add the <code>objectclass: sstProvisioning</code> to this domain.
 <source lang="ldif">
@@ Line 73: / Line 74: @@
 sstOpenStackId: abcdef2477be64c099500224864999998
 sstOpenStackName: Service Provider
-description: Service Provider stepping stone GmbH
+description: Service Provider stepping stone AG
 sstIsActive: TRUE
 sstIsIaaSDomain: FALSE
 sstBillable: FALSE
 sstConsolidatedBill: FALSE
+sstRegion: duedingen_test
 sstBelongsToResellerUID: 4000000
 sstBelongsToCustomerUID: 4000001
 </source>
-==== Domain (reseller) example ====
+==== OpenStack (service) - Domains (resellers) - Domain (reseller) example ====
 The following LDIF example shows a typical OpenStack Domain.
 <source lang="ldif">
@@ Line 97: / Line 99: @@
 sstIsIaaSDomain: FALSE
 sstBillable: TRUE
+sstNonBillableItem: network_id:f7f865e8-a745-455c-80cf-b0a4ea09323c
+sstCancellationDate: 20201231
 sstConsolidatedBill: FALSE
+sstRegion: duedingen_test
 sstProvisioningMode: added
 sstProvisioningExecutionDate: 0
@@ Line 126: / Line 131: @@
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackDomain
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x<sup>3</sup></center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The OpenStack Domain id as returned from the OpenStack API.
@@ Line 169: / Line 174: @@
 |-
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBillable
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackDomain
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| It the entry billable? Either <code>TRUE</code> (yes) or <code>FALSE</code> (no). All hierarchical levels must have <code>sstBillable: TRUE</code> to actually have an invoice generated and sent. If the attribute <code>sstBillable</code> doesn't exist, the default is <code>TRUE</code>. This way, we are forced to set a reseller, customer or product manually to <code>sstBillable: FALSE</code> if we want to avoid sending them an invoice.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstNonBillableItem
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| This multi-valued attribute lists the items, that aren't billable, even if <code>sstBillable</code> is set to <code>TRUE</code>. The following example presumes, that the reseller with <code>sstBelongsToResellerUID: 4000000</code> has their own floating ip range with the OpenStack with the <code>network_id</code> <code>f7f865e8-a745-455c-80cf-b0a4ea09323c</code>.
+Example: <code>sstNonBillableItem: network_id:f7f865e8-a745-455c-80cf-b0a4ea09323c</code>
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstCancellationDate
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackDomain
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: '''20201231'''.
+The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>. With other words: Once the cancellation date has passed, it overrides the <code>sstIsActive</code> value.
 |-
@@ Line 182: / Line 205: @@
 The default value is <code>FALSE</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRegion
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackDomain
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The region tells us, were the infrastructure (domains, projects, networks, servers and more) is to be provisioned. Currently duedingen_production and duedingen_test are
+supported. The default region is duedingen_production.
+The default value is <code>duedingen_production</code>.
 |-
@@ Line 228: / Line 261: @@
 * '''x<sup>1</sup>''': Set <code>sstProvisioningMode</code> to either <code>added</code>, <code>modified</code> or <code>deleted</code> if modifying the entry manually.
 * '''x<sup>2</sup>''': Use <code>date --utc "+%Y%m%dT%H%M%SZ"</code> to set the attribute <code>sstProvisioningState</code> if modifying the entry manually.
+* '''x<sup>3</sup>''': Set by Terraform after the successful provisioning.
-=== Projects (tenants) ===
+=== OpenStack (service) - Projects (tenants) ===
 <source lang="ldif">
 dn: ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 238: / Line 272: @@
 </source>
-==== Project (tenant) examples ====
+==== OpenStack (service) - Projects (tenants) - Examples ====
 Due to the OpenStack project (tenant) organisation, we can have multiple tenants per domain (reseller) and customers. The following LDIF example show the first project of the customer Customer Ltd. with the <code>sstBelongsToCustomerUID: 4000001</code> belonging to the reseller Reseller Ltd. with the <code>sstBelongsToResellerUID: 4000000</code>:
 <source lang="ldif">
@@ Line 257: / Line 291: @@
 sstCancellationDate: 20201231
 sstConsolidatedBill: FALSE
+sstRegion: duedingen_test
 sstProvisioningMode: added
 sstProvisioningExecutionDate: 0
@@ Line 284: / Line 319: @@
 sstBillable: TRUE
 sstConsolidatedBill: FALSE
+sstRegion: duedingen_test
 sstProvisioningMode: added
 sstProvisioningExecutionDate: 0
@@ Line 383: / Line 419: @@
 |-
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstCancellationDate
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackUnit
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackProject
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: '''20201231'''. The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>.
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: '''20201231'''.
+The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>. With other words: Once the cancellation date has passed, it overrides the <code>sstIsActive</code> value.
 |-
@@ Line 396: / Line 434: @@
 The default value is <code>FALSE</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRegion
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackProject
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The region tells us, were the infrastructure (domains, projects, networks, servers and more) is to be provisioned. Currently duedingen_production and duedingen_test are
+supported. The default region is duedingen_production.
+The default value is <code>duedingen_production</code>.
 |-
@@ Line 421: / Line 469: @@
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToDomainID
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackProject
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x<sup>5</sup>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The OpenStack domain id the project belongs to.
@@ Line 453: / Line 501: @@
 * '''x<sup>3</sup>''': Set <code>sstProvisioningMode</code> to either <code>added</code>, <code>modified</code> or <code>deleted</code> if modifying the entry manually.
 * '''x<sup>4</sup>''': Use <code>date --utc "+%Y%m%dT%H%M%SZ"</code> to set the attribute <code>sstProvisioningState</code> if modifying the entry manually.
+* '''x<sup>5</sup>''': The attribute <code>sstBelongsToDomainID</code> is optional, as it will be set during the provisioning of the OpenStack project via OpenTofu (Terraform).
-=== Units (instances) ===
+=== OpenStack (service) - Units (instances) ===
 <source lang="ldif">
 dn: ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 463: / Line 512: @@
 </source>
-==== Unit (instance) examples ====
+==== OpenStack (service) - Units (instances) - Examples ====
 <source lang="ldif">
 dn: uid=4100002,ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org
@@ Line 470: / Line 519: @@
 objectclass: sstProvisioning
 objectclass: sstRelationship
+objectclass: sstConfigurationManagement
 uid: 4100002
 sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4
-sstDisplayName: sst-int-001: stepping stone GmbH: CentOS 7 (Odoo)
+sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)
-description: The leaf for the OpenStack server sst-int-001: stepping stone GmbH: CentOS 7 (Odoo).
+description: The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).
+sstOperatingSystem: Linux
 sstNetworkHostname: sst-int-001
 sstNetworkDomainName: os.stoney-cloud.com
@@ Line 482: / Line 533: @@
 sstProvisioningExecutionDate: 0
 sstProvisioningState: 20180819T083208Z
+sstBusinessLogicRoleName: erp_odoo
+sstRegion: duedingen_production
+sstEnvironment: production
 sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9
 sstBelongsToResellerUID: 4000000
@@ Line 521: / Line 575: @@
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The OpenStack project name as returned from the OpenStack API.
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The human readable display name.
-For example: <code>"name" : "sst-int-001: stepping stone GmbH: CentOS 7 (Odoo)"</code>. This gives us the LDAP entry: <code>sstDisplayName: sst-int-001: stepping stone GmbH: CentOS 7 (Odoo)</code>.
+For example: <code>"name" : "description"</code>. This gives us the LDAP entry: <code>sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)</code>.
 |-
@@ Line 532: / Line 586: @@
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The description is built up as follows: <code>The leaf for the OpenStack server <sstDisplayName>.</code>.
-For example: <code>The leaf for the OpenStack server sst-int-001: stepping stone GmbH: CentOS 7 (Odoo).</code>.
+For example: <code>The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOperatingSystem
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackUnit
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| A manually executed maintenance window for Windows systems is significantly more time-consuming than for Linux. Therefore we need to know the operating system. Possible values are
+* <code>sstOperatingSystem: Linux</code>
+* <code>sstOperatingSystem: Windows</code>.
+This attribute is only relevant, if <code>sstServiceAutomated</code> is set to <code>FALSE</code> (under <code>ou=units,ou=maintenance,ou=services,dc=stoney-cloud,dc=org</code>). See the [[stoney_maintenance:_OpenLDAP_directory_data_organisation#Maintenance_Units |Maintenance units]] documentation.
 |-
@@ Line 573: / Line 638: @@
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
-| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: '''20201231'''. The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>.
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: '''20201231'''.
+The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>. With other words: Once the cancellation date has passed, it overrides the <code>sstIsActive</code> value.
 |-
@@ Line 595: / Line 662: @@
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x<sup>3</sup></center>
 | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The provisioning state, either <code>0</code> or in the form of <code>[YYYY][MM][DD]T[hh][mm][ss]Z</code> ([http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]). Z is the zone designator for the zero UTC offset. For a new OpenStack Unit, this attribute must be set to '''0'''. After the successful provisioning, the value is set to the time of the provisioning. For example: <code>sstProvisioningState: 20180819T083208Z</code>. See the [[stoney_core:_OpenLDAP_provisioning | stoney core: OpenLDAP provisioning]] page for details.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBusinessLogicRoleName
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstConfigurationManagement
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The Puppet role (business logic).
+For example: <code>sstBusinessLogicRoleName: erp_odoo</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRegion
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstConfigurationManagement
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The geographical region.
+For example: <code>sstRegion: duedingen_production</code> or <code>sstRegion: cn_azure_china_east_2</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstEnvironment
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstConfigurationManagement
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The Puppet environment.
+For example: <code>sstEnvironment: production</code>, <code>sstEnvironment: integration</code>, <code>sstEnvironment: test</code> or individual feature branches.
 |-
@@ Line 631: / Line 726: @@
 * '''x<sup>3</sup>''': Use <code>date --utc "+%Y%m%dT%H%M%SZ"</code> to set the attribute <code>sstProvisioningState</code> if modifying the entry manually.
-=== Licences (...) ===
+=== OpenStack (service) - Image backups ===
+<source lang="ldif">
+dn: ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: backups
+description: The sub tree for the image backups of the units (instances) in the OpenStack based stoney cloud service.
+</source>
+==== OpenStack (service) - Image backups - Examples ====
+<source lang="ldif">
+dn: uid=4100004,ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: sstOpenStackImageBackup
+objectclass: sstRelationship
+uid: 4100004
+sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)
+description: The leaf for the image backup of the OpenStack instance 'sst-int-001: stepping stone AG: CentOS 7 (Odoo)'.
+sstBackupIterations: 1
+sstBackupLastSuccessfulBackup: computer:20130923T063554Z
+sstIsActive: TRUE
+sstBillable: TRUE
+sstCancellationDate: 20201231
+sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9
+sstBelongsToUnitID: 9ecb5bfdd4564f6ca52bba1e869eeea4
+sstBelongsToResellerUID: 4000000
+sstBelongsToCustomerUID: 4000001
+sstBelongsToServiceUID: 4000002
+</source>
+Please visit the [[Account Naming]] page and the [[Customer VM Naming Convention]] for the <code>sstNetworkHostnameFormat</code>.
+The following table describes the different attributes:
+{| style="border-spacing:0;"
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| '''Attribute'''
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| '''Objectclass'''
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>'''Existence'''</center>
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>'''Mandatory'''</center>
+| style="border:0.002cm solid #000000;padding:0.097cm;"| '''Description'''
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| uid
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| A unique integer value with 7 digits or more.
+For example: <code>uid: 4100002</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstDisplayName
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The OpenStack project name as returned from the OpenStack API.
+For example: <code>"name" : "sst-int-001: stepping stone AG: CentOS 7 (Odoo)"</code>. This gives us the LDAP entry: <code>sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo)</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| description
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The description is built up as follows: <code>The leaf for the OpenStack server <sstDisplayName>.</code>.
+For example: <code>The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBackupIterations
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The number of image backup iterations. Possible values are between 0 and 9999. Default is <code>1</code>.
+For example: <code>sstBackupIterations: 1</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBackupLastSuccessfulBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The date and time of the last successful image backup in UTC, either 0 or in the form of <code>[YYYY][MM][DD]T[hh][mm][ss]Z</code> (ISO 8601).
+For example: <code>sstBackupLastSuccessfulBackup: 20130923T063554Z</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstIsActive
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Is the entry active? Either <code>TRUE</code> (yes) or <code>FALSE</code> (no).
+The default value is <code>TRUE</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBillable
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| It the entry billable? Either <code>TRUE</code> (yes) or <code>FALSE</code> (no). All hierarchical levels must have <code>sstBillable: TRUE</code> to actually have an invoice generated and sent. If the attribute <code>sstBillable</code> doesn't exist, the default is <code>TRUE</code>. This way, we are forced to set a reseller, customer or product manually to <code>sstBillable: FALSE</code> if we want to avoid sending them an invoice.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstCancellationDate
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601).
+For example: <code>sstCancellationDate: 20201231</code>.
+The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>. With other words: Once the cancellation date has passed, it overrides the <code>sstIsActive</code> value.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToProjectID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The OpenStack project id the project belongs to.
+For example: <code>sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToUnitID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOpenStackImageBackup
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x<sup>1</sup></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The OpenStack unit id as returned from the OpenStack API.
+For example: <code>sstBelongsToUnitID: 9ecb5bfdd4564f6ca52bba1e869eeea4</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToResellerUID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more.
+For example: <code>sstBelongsToResellerUID: 4000000</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToCustomerUID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute <code>sstBelongsToCustomerUID</code> should always be set to the customer UID, that reflects the reseller for the OpenStack Domains.
+For example: <code>sstBelongsToCustomerUID: 4000001</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToServiceUID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Stores the UID (Unique Identifier) of the service the leaf belongs to. This UID can be used to look up other information. For example, if the attribute sstBelongsToUnitID is missing, we can look this value up (and maybe update it at the same time to spare future lookups).
+For example: <code>sstBelongsToServiceUID: 4000002</code>.
+|}
+Legend:
+* '''x''': Mandatory in all cases.
+* '''x<sup>1</sup>''': Must be set after the provisioning, as OpenStack doesn't allow to set ids.
+=== OpenStack (service) - Licences (...) ===
 Is a main service, not a sub service of the openstack service.
 <source lang="ldif">
@@ Line 641: / Line 899: @@
 </source>
-==== Licences (...) examples ====
+==== OpenStack (service) - Licences (...) - Examples ====
 ...
 <source lang="ldif">
@@ Line 658: / Line 916: @@
 sstBelongsToServiceUID <- What value? Will this cause a ldap search over all the services?
 </source>
+== OpenStack (infrastructure) ==
+The sub tree <code>ou=dedicated servers,ou=service,dc=stoney-cloud,dc=org</code> contains all the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs) information.
+<source lang='ldif'>
+dn: ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: organizationalUnit
+description: This sub tree contains all the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs) information.
+ou: openstack
+</source>
+=== OpenStack (infrastructure) - Configuration ===
+<source lang='ldif'>
+dn: ou=configuration,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: configuration
+description: The sub tree for the configuration of all the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs).
+</source>
+==== OpenStack (infrastructure) - Configuration - Resellers ====
+<source lang='ldif'>
+dn: ou=reseller,ou=configuration,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: reseller
+description: The sub tree for the reseller specific configuration of the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs).
+</source>
+=== OpenStack (infrastructure) - Units (control-, compute- and storage-nodes as well as the control virtual machines) ===
+<source lang='ldif'>
+dn: ou=units,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: units
+description: The sub tree for the OpenStack control-, compute- and storage-nodes as well as the control virtual machines (VMs), called units.
+</source>
+==== OpenStack (infrastructure) - Unit (control-, compute- and storage-nodes as well as the control virtual machines) - Examples ====
+Some concrete naming examples of the OpenStack control-, compute- and storage nodes as well as the control virtual machines (VMs):
+'''Control nodes:'''
+* ctrl-node-001: stepping stone AG: CentOS 7 (Control), with the Puppet role <code>cloud_openstack_control</code>
+* ctrl-node-002: stepping stone AG: CentOS 7 (Control), with the Puppet role <code>cloud_openstack_control</code>
+'''Compute nodes:'''
+* compute-node-001: stepping stone AG: CentOS 7 (Compute), with the Puppet role <code>cloud_openstack_compute</code>
+* compute-node-002: stepping stone AG: CentOS 7 (Compute), with the Puppet role <code>cloud_openstack_compute</code>
+'''Storage nodes:'''
+* storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor), with the Puppet role <code>storage_ceph</code>
+* storage-node-002: stepping stone AG: CentOS 7 (Ceph monitor), with the Puppet role <code>storage_ceph</code>
+* storage-node-003: stepping stone AG: CentOS 7 (Ceph storage), with the Puppet role <code>storage_ceph</code>
+'''Control VMs:'''
+* ctrl-vm-020: stepping stone AG: CentOS 7 (Ceph monitor), with the Puppet role <code>storage_ceph</code>
+* ctrl-vm-021: stepping stone AG: CentOS 7 (Glance), with the Puppet role <code>cloud_openstack_glance</code>
+The following LDIF shows a complete example of storage node with the Puppet role <code>storage_ceph</code>.
+<source lang='ldif'>
+dn: uid=4100002,ou=units,ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org
+objectclass: top
+objectclass: sstServer
+objectclass: sstRelationship
+objectclass: sstConfigurationManagement
+uid: 4100002
+sstDisplayName: storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor)
+description: The leaf for the OpenStack infrastructure server storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor).
+sstNetworkHostname: storage-node-001
+sstNetworkDomainName: ctrl-int.os.stoney-cloud.com
+sstIsActive: TRUE
+sstBillable: FALSE
+sstBusinessLogicRoleName: storage_ceph
+sstRegion: duedingen_production
+sstEnvironment: production
+sstBelongsToProjectID: 6907bf36283fee21f1396b803d041041
+sstBelongsToResellerUID: 4000000
+sstBelongsToCustomerUID: 4000001
+</source>
+Please visit the [[Account Naming]] page and the [[Customer VM Naming Convention]] for the <code>sstNetworkHostnameFormat</code>.
+The following table describes the different attributes:
+{| style="border-spacing:0;"
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| '''Attribute'''
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| '''Objectclass'''
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>'''Existence'''</center>
+| style="border-top:0.002cm solid #000000;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>'''Mandatory'''</center>
+| style="border:0.002cm solid #000000;padding:0.097cm;"| '''Description'''
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| uid
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| A unique integer value with 7 digits or more.
+For example: <code>uid: 4100002</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstDisplayName
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The human readable display name.
+For example: <code>"name" : "description"</code>. This gives us the LDAP entry: <code>sstDisplayName: storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor)</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| description
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The description is built up as follows: <code>The leaf for the OpenStack server <sstDisplayName>.</code>.
+For example: <code>The leaf for the OpenStack server storage-node-001: stepping stone AG: CentOS 7 (Ceph monitor).</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstOperatingSystem
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| A manually executed maintenance window for Windows systems is significantly more time-consuming than for Linux. Therefore we need to know the operating system. Possible values are
+* <code>sstOperatingSystem: Linux</code>
+* <code>sstOperatingSystem: Windows</code>.
+This attribute is only relevant, if <code>sstServiceAutomated</code> is set to <code>FALSE</code> (under <code>ou=units,ou=maintenance,ou=services,dc=stoney-cloud,dc=org</code>). See the [[stoney_maintenance:_OpenLDAP_directory_data_organisation#Maintenance_Units |Maintenance units]] documentation.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstNetworkHostname
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The host name of the unit according to the rules defined in [[Account Naming]] and [[Customer VM Naming Convention]].
+For example: <code>sst-int-001</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstNetworkDomainName
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The domain name of the unit.
+For example: <code>ctrl-int.os.stoney-cloud.com</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstIsActive
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Is the entry active? Either <code>TRUE</code> (yes) or <code>FALSE</code> (no).
+The default value is <code>TRUE</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBillable
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| It the entry billable? Either <code>TRUE</code> (yes) or <code>FALSE</code> (no). All hierarchical levels must have <code>sstBillable: TRUE</code> to actually have an invoice generated and sent. If the attribute <code>sstBillable</code> doesn't exist, the default is <code>TRUE</code>. This way, we are forced to set a reseller, customer or product manually to <code>sstBillable: FALSE</code> if we want to avoid sending them an invoice.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstCancellationDate
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: '''20201231'''.
+The attribute <code>sstCancellationDate</code> is used in a logical AND combination with <code>sstIsActive</code>. With other words: Once the cancellation date has passed, it overrides the <code>sstIsActive</code> value.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBusinessLogicRoleName
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstConfigurationManagement
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MUST</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The Puppet role (business logic).
+For example: <code>sstBusinessLogicRoleName: storage_ceph</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRegion
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstConfigurationManagement
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The geographical region.
+For example: <code>sstRegion: duedingen_production</code> or <code>sstRegion: cn_azure_china_east_2</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstEnvironment
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstConfigurationManagement
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| The Puppet environment.
+For example: <code>sstEnvironment: production</code>, <code>sstEnvironment: integration</code>, <code>sstEnvironment: test</code> or individual feature branches.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToProjectID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstServer
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center></center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"|  The (virtual) OpenStack project id the project belongs to. The project id used by the configuration management system Puppet via enc.
+For example: <code>6907bf36283fee21f1396b803d041041</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToResellerUID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more.
+For example: <code>sstBelongsToResellerUID: 4000000</code>.
+|-
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstBelongsToCustomerUID
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| sstRelationship
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>MAY</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <center>x</center>
+| style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:0.002cm solid #000000;padding:0.097cm;"| Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute <code>sstBelongsToCustomerUID</code> should always be set to the customer UID, that reflects the reseller for the OpenStack Domains.
+For example: <code>sstBelongsToCustomerUID: 4000001</code>.
+|}
+Legend:
+* '''x''': Mandatory in all cases.
 == Questions ==