Difference between revisions of "stoney cloud: OpenLDAP directory data organisation"
[checked revision] | [checked revision] |
(→Image backup examples) |
(→OpenStack (service) - Projects (tenants) - Examples) |
||
(42 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
= Data Organisation = | = 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. |
− | == | + | == 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 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"> | <source lang="ldif"> | ||
dn: ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 17: | Line 17: | ||
</source> | </source> | ||
− | === Configuration === | + | === OpenStack (service) - Configuration === |
<source lang="ldif"> | <source lang="ldif"> | ||
dn: ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 26: | Line 26: | ||
</source> | </source> | ||
− | ==== | + | ==== OpenStack (service) - Configuration - Resellers ==== |
<source lang="ldif"> | <source lang="ldif"> | ||
dn: ou=reseller,ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=reseller,ou=configuration,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 35: | Line 35: | ||
</source> | </source> | ||
− | === Domains (resellers) === | + | === OpenStack (service) - Domains (resellers) === |
<source lang="ldif"> | <source lang="ldif"> | ||
dn: ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=domains,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 44: | Line 44: | ||
</source> | </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. | 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"> | <source lang="ldif"> | ||
Line 59: | Line 59: | ||
sstBillable: FALSE | sstBillable: FALSE | ||
sstConsolidatedBill: FALSE | sstConsolidatedBill: FALSE | ||
+ | sstRegion: duedingen_test | ||
sstBelongsToResellerUID: 4000000 | sstBelongsToResellerUID: 4000000 | ||
sstBelongsToCustomerUID: 4000001 | sstBelongsToCustomerUID: 4000001 | ||
</source> | </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. | 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"> | <source lang="ldif"> | ||
Line 73: | Line 74: | ||
sstOpenStackId: abcdef2477be64c099500224864999998 | sstOpenStackId: abcdef2477be64c099500224864999998 | ||
sstOpenStackName: Service Provider | sstOpenStackName: Service Provider | ||
− | description: Service Provider stepping stone | + | description: Service Provider stepping stone AG |
sstIsActive: TRUE | sstIsActive: TRUE | ||
sstIsIaaSDomain: FALSE | sstIsIaaSDomain: FALSE | ||
sstBillable: FALSE | sstBillable: FALSE | ||
sstConsolidatedBill: FALSE | sstConsolidatedBill: FALSE | ||
+ | sstRegion: duedingen_test | ||
sstBelongsToResellerUID: 4000000 | sstBelongsToResellerUID: 4000000 | ||
sstBelongsToCustomerUID: 4000001 | sstBelongsToCustomerUID: 4000001 | ||
</source> | </source> | ||
− | ==== Domain (reseller) example ==== | + | ==== OpenStack (service) - Domains (resellers) - Domain (reseller) example ==== |
The following LDIF example shows a typical OpenStack Domain. | The following LDIF example shows a typical OpenStack Domain. | ||
<source lang="ldif"> | <source lang="ldif"> | ||
Line 100: | Line 102: | ||
sstCancellationDate: 20201231 | sstCancellationDate: 20201231 | ||
sstConsolidatedBill: FALSE | sstConsolidatedBill: FALSE | ||
+ | sstRegion: duedingen_test | ||
sstProvisioningMode: added | sstProvisioningMode: added | ||
sstProvisioningExecutionDate: 0 | sstProvisioningExecutionDate: 0 | ||
Line 128: | 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;"| 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>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. | | 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 202: | Line 205: | ||
The default value is <code>FALSE</code>. | 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 248: | 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>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>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"> | <source lang="ldif"> | ||
dn: ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=projects,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 258: | Line 272: | ||
</source> | </source> | ||
− | ==== | + | ==== 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>: | 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"> | <source lang="ldif"> | ||
Line 277: | Line 291: | ||
sstCancellationDate: 20201231 | sstCancellationDate: 20201231 | ||
sstConsolidatedBill: FALSE | sstConsolidatedBill: FALSE | ||
+ | sstRegion: duedingen_test | ||
sstProvisioningMode: added | sstProvisioningMode: added | ||
sstProvisioningExecutionDate: 0 | sstProvisioningExecutionDate: 0 | ||
Line 304: | Line 319: | ||
sstBillable: TRUE | sstBillable: TRUE | ||
sstConsolidatedBill: FALSE | sstConsolidatedBill: FALSE | ||
+ | sstRegion: duedingen_test | ||
sstProvisioningMode: added | sstProvisioningMode: added | ||
sstProvisioningExecutionDate: 0 | sstProvisioningExecutionDate: 0 | ||
Line 418: | Line 434: | ||
The default value is <code>FALSE</code>. | 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 443: | 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;"| 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;"| sstOpenStackProject | ||
− | | style="border-top:none;border-bottom:0.002cm solid #000000;border-left:0.002cm solid #000000;border-right:none;padding:0.097cm;"| <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</ | + | | 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. | | 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 475: | 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>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>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"> | <source lang="ldif"> | ||
dn: ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 485: | Line 512: | ||
</source> | </source> | ||
− | ==== | + | ==== OpenStack (service) - Units (instances) - Examples ==== |
<source lang="ldif"> | <source lang="ldif"> | ||
dn: uid=4100002,ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: uid=4100002,ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 495: | Line 522: | ||
uid: 4100002 | uid: 4100002 | ||
sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4 | sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4 | ||
− | sstDisplayName: sst-int-001: stepping stone | + | sstDisplayName: sst-int-001: stepping stone AG: CentOS 7 (Odoo) |
− | description: The leaf for the OpenStack server sst-int-001: stepping stone | + | description: The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo). |
sstOperatingSystem: Linux | sstOperatingSystem: Linux | ||
sstNetworkHostname: sst-int-001 | sstNetworkHostname: sst-int-001 | ||
Line 548: | 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>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: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 | + | | 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" : " | + | 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 559: | 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>. | | 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 | + | For example: <code>The leaf for the OpenStack server sst-int-001: stepping stone AG: CentOS 7 (Odoo).</code>. |
|- | |- | ||
Line 699: | 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. | * '''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. | ||
− | === Image backups === | + | === OpenStack (service) - Image backups === |
<source lang="ldif"> | <source lang="ldif"> | ||
dn: ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
objectclass: top | objectclass: top | ||
objectclass: organizationalUnit | objectclass: organizationalUnit | ||
− | ou: | + | ou: backups |
description: The sub tree for the image backups of the units (instances) in the OpenStack based stoney cloud service. | description: The sub tree for the image backups of the units (instances) in the OpenStack based stoney cloud service. | ||
</source> | </source> | ||
− | ==== Image | + | ==== OpenStack (service) - Image backups - Examples ==== |
<source lang="ldif"> | <source lang="ldif"> | ||
dn: uid=4100004,ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org | dn: uid=4100004,ou=backups,ou=openstack,ou=services,dc=stoney-cloud,dc=org | ||
Line 722: | Line 749: | ||
sstBillable: TRUE | sstBillable: TRUE | ||
sstCancellationDate: 20201231 | sstCancellationDate: 20201231 | ||
− | |||
sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9 | sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9 | ||
+ | sstBelongsToUnitID: 9ecb5bfdd4564f6ca52bba1e869eeea4 | ||
sstBelongsToResellerUID: 4000000 | sstBelongsToResellerUID: 4000000 | ||
sstBelongsToCustomerUID: 4000001 | sstBelongsToCustomerUID: 4000001 | ||
− | sstBelongsToServiceUID: | + | sstBelongsToServiceUID: 4000002 |
</source> | </source> | ||
Line 732: | Line 759: | ||
The following table describes the different attributes: | The following table describes the different attributes: | ||
− | |||
{| style="border-spacing:0;" | {| 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;"| '''Attribute''' | ||
Line 772: | Line 798: | ||
| 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>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: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 | + | | 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>. | For example: <code>sstBackupIterations: 1</code>. | ||
Line 811: | Line 837: | ||
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. | 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 829: | Line 846: | ||
For example: <code>sstBelongsToProjectID: 5a3a4fd5d6e94a87815131be42d8e6d9</code>. | 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>. | ||
|- | |- | ||
Line 847: | Line 873: | ||
For example: <code>sstBelongsToCustomerUID: 4000001</code>. | 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>. | ||
|} | |} | ||
Line 853: | Line 888: | ||
* '''x''': Mandatory in all cases. | * '''x''': Mandatory in all cases. | ||
* '''x<sup>1</sup>''': Must be set after the provisioning, as OpenStack doesn't allow to set ids. | * '''x<sup>1</sup>''': Must be set after the provisioning, as OpenStack doesn't allow to set ids. | ||
− | |||
− | |||
− | === Licences (...) === | + | === OpenStack (service) - Licences (...) === |
Is a main service, not a sub service of the openstack service. | Is a main service, not a sub service of the openstack service. | ||
<source lang="ldif"> | <source lang="ldif"> | ||
Line 866: | Line 899: | ||
</source> | </source> | ||
− | ==== Licences (...) | + | ==== OpenStack (service) - Licences (...) - Examples ==== |
... | ... | ||
<source lang="ldif"> | <source lang="ldif"> | ||
Line 883: | Line 916: | ||
sstBelongsToServiceUID <- What value? Will this cause a ldap search over all the services? | sstBelongsToServiceUID <- What value? Will this cause a ldap search over all the services? | ||
</source> | </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 == | == Questions == |
Latest revision as of 11:30, 23 March 2024
Contents
- 1 Abstract
- 2 Introduction
- 3 Data Organisation
- 3.1 OpenStack (service)
- 3.2 OpenStack (infrastructure)
- 3.3 Questions
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 | |
|
Description |
uid | sstOpenStackDomain | |
|
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: |
sstOpenStackId | sstOpenStackDomain | |
|
The OpenStack Domain id as returned from the OpenStack API.
For example: |
sstOpenStackName | sstOpenStackDomain | |
|
The OpenStack Domain name as returned from the OpenStack API.
For example: |
description | sstOpenStackDomain | |
|
The description is built up as follows: <sstBelongsToResellerUID> - <sstOpenStackName> .
For example: |
sstIsActive | sstOpenStackDomain | |
|
Is the entry active? Either TRUE (yes) or FALSE (no).
The default value is |
sstIsIaaSDomain | sstOpenStackDomain | |
|
Is the OpenStack based Domain (reseller) a Infrastructure as a Service (IaaS) Domain? Either yes (TRUE) or no (FALSE).
The default value is |
sstBillable | sstOpenStackDomain | |
|
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 | |
|
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: |
sstCancellationDate | sstOpenStackDomain | |
|
The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231.
The attribute |
sstConsolidatedBill | sstOpenStackDomain | |
|
Do we want to have a consolidated bill for the OpenStack Domain? Either yes (TRUE) or no (FALSE).
The default value is |
sstRegion | sstOpenStackDomain | |
|
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 |
sstProvisioningMode | sstProvisioning | |
|
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 | |
|
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 | |
|
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 | |
|
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: |
sstBelongsToCustomerUID | sstRelationship | |
|
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: |
Legend:
- x: Mandatory in all cases.
- x1: Set
sstProvisioningMode
to eitheradded
,modified
ordeleted
if modifying the entry manually. - x2: Use
date --utc "+%Y%m%dT%H%M%SZ"
to set the attributesstProvisioningState
if modifying the entry manually. - x3: 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 | |
|
Description |
uid | sstOpenStackProject | |
|
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: |
sstOpenStackId | sstOpenStackProject | |
|
The OpenStack project id as returned from the OpenStack API.
For example: |
sstOpenStackName | sstOpenStackProject | |
|
The OpenStack project name as returned from the OpenStack API.
For example: |
description | sstOpenStackProject | |
|
The description is built up as follows: <sstBelongsToResellerUID>/<sstBelongsToCustomerUID> - <sstOpenStackName> .
For example: |
sstNetworkHostnameFormat | sstOpenStackProject | |
|
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 | sstOpenStackProject | |
|
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: |
sstIsActive | sstOpenStackProject | |
|
Is the entry active? Either TRUE (yes) or FALSE (no).
The default value is |
sstIsIaaSProject | sstOpenStackProject | |
|
Is the OpenStack based Project (tenant) a Infrastructure as a Service (IaaS) Project? Either yes (TRUE) or no (FALSE).
The default value is |
sstBillable | sstOpenStackProject | |
|
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 | |
|
The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231.
The attribute |
sstConsolidatedBill | sstOpenStackProject | |
|
Do we want to have a consolidated bill for the OpenStack Project? Either yes (TRUE) or no (FALSE).
The default value is |
sstRegion | sstOpenStackProject | |
|
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 |
sstProvisioningMode | sstProvisioning | |
|
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 | |
|
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 | |
|
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 | |
|
The OpenStack domain id the project belongs to.
For example: |
sstBelongsToResellerUID | sstRelationship | <center>MAY | |
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: |
sstBelongsToCustomerUID | sstRelationship | |
|
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: |
Legend:
- x: Mandatory in all cases.
- x1: If
sstIsIaaSProject
is set toFALSE
, the attributesstNetworkHostnameFormat
must be set manually. IfsstIsIaaSProject
is set toTRUE
, the attributesstNetworkHostnameFormat
must not be set (is not allowed). - x2: If
sstIsIaaSProject
is set toFALSE
, the attributesstNetworkHostnameNextFreeNumber
it must be set manually. IfsstIsIaaSProject
is set toTRUE
, the attributesstNetworkHostnameNextFreeNumber
must not be set (is not allowed). - x3: Set
sstProvisioningMode
to eitheradded
,modified
ordeleted
if modifying the entry manually. - x4: Use
date --utc "+%Y%m%dT%H%M%SZ"
to set the attributesstProvisioningState
if modifying the entry manually. - x5: 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 | |
|
Description |
uid | sstOpenStackUnit | |
|
A unique integer value with 7 digits or more.
For example: |
sstOpenStackId | sstOpenStackUnit | |
|
The OpenStack unit id as returned from the OpenStack API.
For example: |
sstDisplayName | sstOpenStackUnit | |
|
The human readable display name.
For example: |
description | sstOpenStackUnit | |
|
The description is built up as follows: The leaf for the OpenStack server <sstDisplayName>. .
For example: |
sstOperatingSystem | sstOpenStackUnit | |
|
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
This attribute is only relevant, if |
sstNetworkHostname | sstOpenStackUnit | |
|
The host name of the unit according to the rules defined in Account Naming and Customer VM Naming Convention.
For example: |
sstNetworkDomainName | sstOpenStackUnit | |
|
The domain name of the unit.
For example: |
sstIsActive | sstOpenStackUnit | |
|
Is the entry active? Either TRUE (yes) or FALSE (no).
The default value is |
sstBillable | sstOpenStackUnit | |
|
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 | |
|
The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231.
The attribute |
sstProvisioningMode | sstProvisioning | |
|
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 | |
|
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 | |
|
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 | |
|
The Puppet role (business logic).
For example: |
sstRegion | sstConfigurationManagement | |
|
The geographical region.
For example: |
sstEnvironment | sstConfigurationManagement | |
|
The Puppet environment.
For example: |
sstBelongsToProjectID | sstOpenStackUnit | |
|
The OpenStack project id the project belongs to.
For example: |
sstBelongsToResellerUID | sstRelationship | |
|
Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more.
For example: |
sstBelongsToCustomerUID | sstRelationship | |
|
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: |
Legend:
- x: Mandatory in all cases.
- x1: Must be set after the provisioning, as OpenStack doesn't allow to set ids.
- x2: Set
sstProvisioningMode
to eitheradded
,modified
ordeleted
if modifying the entry manually. - x3: Use
date --utc "+%Y%m%dT%H%M%SZ"
to set the attributesstProvisioningState
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 | |
|
Description |
uid | sstOpenStackImageBackup | |
|
A unique integer value with 7 digits or more.
For example: |
sstDisplayName | sstOpenStackImageBackup | |
|
The OpenStack project name as returned from the OpenStack API.
For example: |
description | sstOpenStackImageBackup | |
|
The description is built up as follows: The leaf for the OpenStack server <sstDisplayName>. .
For example: |
sstBackupIterations | sstOpenStackImageBackup | |
|
The number of image backup iterations. Possible values are between 0 and 9999. Default is 1 .
For example: |
sstBackupLastSuccessfulBackup | sstOpenStackImageBackup | |
|
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: |
sstIsActive | sstOpenStackImageBackup | |
|
Is the entry active? Either TRUE (yes) or FALSE (no).
The default value is |
sstBillable | sstOpenStackImageBackup | |
|
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 | |
|
The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601).
For example: The attribute |
sstBelongsToProjectID | sstOpenStackImageBackup | |
|
The OpenStack project id the project belongs to.
For example: |
sstBelongsToUnitID | sstOpenStackImageBackup | |
|
The OpenStack unit id as returned from the OpenStack API.
For example: |
sstBelongsToResellerUID | sstRelationship | |
|
Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more.
For example: |
sstBelongsToCustomerUID | sstRelationship | |
|
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: |
sstBelongsToServiceUID | sstRelationship | |
|
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: |
Legend:
- x: Mandatory in all cases.
- x1: 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 | |
|
Description |
uid | sstServer | |
|
A unique integer value with 7 digits or more.
For example: |
sstDisplayName | sstServer | |
|
The human readable display name.
For example: |
description | sstServer | |
|
The description is built up as follows: The leaf for the OpenStack server <sstDisplayName>. .
For example: |
sstOperatingSystem | sstServer | |
|
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
This attribute is only relevant, if |
sstNetworkHostname | sstServer | |
|
The host name of the unit according to the rules defined in Account Naming and Customer VM Naming Convention.
For example: |
sstNetworkDomainName | sstServer | |
|
The domain name of the unit.
For example: |
sstIsActive | sstRelationship | |
|
Is the entry active? Either TRUE (yes) or FALSE (no).
The default value is |
sstBillable | sstRelationship | |
|
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 | |
|
The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231.
The attribute |
sstBusinessLogicRoleName | sstConfigurationManagement | |
|
The Puppet role (business logic).
For example: |
sstRegion | sstConfigurationManagement | |
|
The geographical region.
For example: |
sstEnvironment | sstConfigurationManagement | |
|
The Puppet environment.
For example: |
sstBelongsToProjectID | sstServer | |
|
The (virtual) OpenStack project id the project belongs to. The project id used by the configuration management system Puppet via enc.
For example: |
sstBelongsToResellerUID | sstRelationship | |
|
Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more.
For example: |
sstBelongsToCustomerUID | sstRelationship | |
|
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: |
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?