Difference between revisions of "stoney cloud: OpenLDAP directory data organisation"
[checked revision] | [checked revision] |
(→Domain (OpenStack Service Provider Domain) example) |
(→Domain (reseller) example) |
||
Line 92: | Line 92: | ||
description: 4000000 - Reseller Ltd. | description: 4000000 - Reseller Ltd. | ||
sstIsActive: TRUE | sstIsActive: TRUE | ||
− | |||
sstProvisioningMode: added | sstProvisioningMode: added | ||
sstProvisioningExecutionDate: 0 | sstProvisioningExecutionDate: 0 | ||
sstProvisioningState: 20180819T083208Z | sstProvisioningState: 20180819T083208Z | ||
sstBelongsToResellerUID: 4000000 | sstBelongsToResellerUID: 4000000 | ||
− | |||
− | |||
</source> | </source> | ||
+ | Notes | ||
+ | * <code>sstBillable: FALSE</code> If the attribute doesn't exist, it will take the value from the reseller ou=billing sub tree. | ||
+ | * <code>sstBelongsToCustomerUID: 4000001</code> Not necessary. | ||
+ | * <code>sstBelongsToPersonUID: 4000002</code> Not necessary. | ||
=== Projects (tenants) === | === Projects (tenants) === |
Revision as of 13:57, 25 August 2018
Contents
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 do '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.
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?