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: iaas

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 (reseller) example

dn: uid=4000000,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstIaaSDomains (or just sstIaaS?)
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 5000000
sstDomainID: b01822477be64c09950022486300c59c
sstDomainName: Reseller Ltd.
sstDomainDescription: 4000000 - Reseller Ltd.
sstIsActive: TRUE
sstProvisioningMode: add
sstProvisioningExecutionDate: 0
sstProvisioningState: 0
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

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=5000001,ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstIaaSProjects (or just sstIaaS?)
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 5000001
sstProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9
sstProjectName: Customer Ltd. - Base Project
sstProjectDescription: 4000000/4000001 - Customer Ltd.
sstIsActive: TRUE
sstProvisioningMode: add
sstProvisioningExecutionDate: 0
sstProvisioningState: 0
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

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=5000002,ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstIaaSProjects (or just sstIaaS?)
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 5000002
sstProjectID: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstProjectName: Customer Ltd. - Second Project
sstProjectDescription: Customer Ltd. - Second Project
sstIsActive: TRUE
sstProvisioningMode: add
sstProvisioningExecutionDate: 0
sstProvisioningState: 0
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

Per Domain:

sstBillable: TRUE

Per Project:

sstBillable: TRUE
sstNetworkHostnameFormat: sst-internal-%03d (string)
sstNetworkHostnameNextFreeNumber: 1 (int)

objectclass: sstHostnameDefinitionObjectClass
objectclass: sstOpenStackProject
objectclass: sstOpenStackDomain

To set the attribute sstNetworkHostnameFormat correctly, please read the Customer VM Naming Convention page first!

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?