stoney cloud: OpenLDAP directory data organisation

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 stoney cloud OpenLDAP directory, in this case we looking at the stoney cloud service.

IaaS (Infrastructure as a Service)

The subtree ou=openstack,ou=service,dc=stoney-cloud,dc=org contains all the OpenStack based stoney cloud service data. The following LDIF shows the iaas entry for the stoney cloud service:

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

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.

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.

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.

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
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

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 GmbH
sstIsActive: TRUE
sstIsIaaSDomain: FALSE
sstBillable: FALSE
sstConsolidatedBill: FALSE
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

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
sstConsolidatedBill: FALSE
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	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.
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.
sstProvisioningMode	sstProvisioning	MUST	x1	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	x2	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.

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.

Project (tenant) 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
sstConsolidatedBill: FALSE
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
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	x1	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	x2	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.
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.
sstProvisioningMode	sstProvisioning	MUST	x3	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	x4	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.
sstBelongsToDomainID	sstOpenStackProject	MUST	x	The OpenStack domain id the project belongs to. For example: sstBelongsToDomainID: b01822477be64c09950022486300c59c.
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¹: 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.

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.

Unit (instance) examples

dn: uid=4100002,ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackUnit
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 4100002
sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstDisplayName: sst-int-001: stepping stone GmbH: CentOS 7 (Odoo)
description: The leaf for the OpenStack server sst-int-001: stepping stone GmbH: CentOS 7 (Odoo).
sstNetworkHostname: sst-int-001
sstNetworkDomainName: os.stoney-cloud.com
sstIsActive: TRUE
sstBillable: TRUE
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
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	x1	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 OpenStack project name as returned from the OpenStack API. For example: "name" : "sst-int-001: stepping stone GmbH: CentOS 7 (Odoo)". This gives us the LDAP entry: sstDisplayName: sst-int-001: stepping stone GmbH: 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 GmbH: CentOS 7 (Odoo)..
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.
sstProvisioningMode	sstProvisioning	MUST	x2	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	x3	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.
sstBelongsToProjectID	sstOpenStackUnit	MUST	x	The OpenStack domain id the project belongs to. For example: sstBelongsToDomainID: 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.

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 ...

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?

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?