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

From stoney cloud
Jump to: navigation, search
[checked revision][checked revision]
(→‎Domain (reseller) example)
(→‎Domain (OpenStack Default Domain) example)
Line 45: Line 45:
  
 
==== Domain (OpenStack Default Domain) example ====
 
==== Domain (OpenStack Default Domain) example ====
−
This is a very special domain and is created during the bootstrapping phase of the OpenStack installation. Therefore we do '''never'' provision this domain and we don't add the <code>objectclass: sstProvisioning</code> to this domain.
+
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 don't add the <code>objectclass: sstProvisioning</code> to this domain.
 
<source lang="ldif">
 
<source lang="ldif">
 
dn: uid=4999999,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
 
dn: uid=4999999,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org

Revision as of 14:15, 25 August 2018

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 don't add the objectclass: sstProvisioning to this domain. 

dn: uid=4999999,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackDomain
objectclass: sstRelationship
uid: 4999999
sstOpenStackId: default
sstOpenStackName: Default
description: The default domain
sstIsActive: TRUE
sstBillable: FALSE
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

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 do 'never provision this domain and we don't add the objectclass: sstProvisioning to this domain. 

dn: uid=4999998,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackDomain
objectclass: sstRelationship
uid: 4999998
sstOpenStackId: abcdef2477be64c099500224864999998
sstOpenStackName: Service Provider
description: Service Provider stepping stone GmbH
sstIsActive: TRUE
sstBillable: FALSE
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

Domain (reseller) example

dn: uid=5000000,ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackDomain
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 5000000
sstOpenStackId: b01822477be64c09950022486300c59c
sstOpenStackName: Reseller Ltd.
description: 4000000 - Reseller Ltd.
sstIsActive: TRUE
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBelongsToResellerUID: 4000000

Notes

  • sstBillable: FALSE If the attribute doesn't exist, it will take the value from the reseller ou=billing sub tree.
  • sstBelongsToCustomerUID: 4000001 Not necessary.
  • sstBelongsToPersonUID: 4000002 Not necessary.
  • Use date --utc "+%Y%m%dT%H%M%SZ" to set the attribute sstProvisioningState 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=5100000,ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackProject
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 5100000
sstOpenStackId: 5a3a4fd5d6e94a87815131be42d8e6d9
sstOpenStackName: Customer Ltd. - Internal Systems
description: 4000000/4000001 - Customer Ltd. - Internal Systems
sstNetworkHostnameFormat: cur-int-%03d
sstNetworkHostnameNextFreeNumber: 1
sstIsActive: TRUE
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

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=5100001,ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackProject
objectclass: sstProvisioning
objectclass: sstRelationship
uid: 5100001
sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstOpenStackName: Customer Ltd. - Public Systems
description: 4000000/4000001 - Customer Ltd. - Public Systems
sstNetworkHostnameFormat: cur-pub-%03d
sstNetworkHostnameNextFreeNumber: 1
sstIsActive: TRUE
sstProvisioningMode: added
sstProvisioningExecutionDate: 0
sstProvisioningState: 20180819T083208Z
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

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

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?
Retrieved from "https://wiki.stoney-cloud.org/mediawiki/index.php?title=stoney_cloud:_OpenLDAP_directory_data_organisation&oldid=4780"