Align Volume (Block Storage) capabilities description between SCS and Gaia-X

[anjastrunk]

There exists a SCS decision record and a standard on volume types and a base class, called Storage Service Offering to describe storage capabilities. Both have to be aligned.

[anjastrunk]

StorageServiceOffering has three different sub-classes:

classDiagram

StorageServiceOffering <|-- FileStorageServiceOffering
StorageServiceOffering <|-- BlockServiceStorageOffering
StorageServiceOffering <|-- ObjectServiceStorageOffering

As volumes are of type block storage, we have to investigate BlockStorageServiceOffering

[anjastrunk]

The following attributes are mentioned in SCS Volume Type Decision Record:

• encryption: encryption-provider, key size, cipher and control location
• volume type name
• availability zone
• multiattach
• number of replications
• QoS

The following attributes are part of SCS Volume Type Standard:

• encryption
• replication

Gaia-X class BlockStorageServiceOffering offers the following attributes:

• providedBy (mandatory)
• dependsOn
• serviceOfferingTermsAndConditions (mandatory)
• servicePolicy (mandatory)
• dataProtectionRegime
• dataAccountExport (mandatory)
• keyword
• provisionType
• endpoint
• hostedOn
• serviceScope
• legalDocuments
• subContractors
• customerInstructions
• dataPortability
• possiblePersonalDataTransfers
• requiredMeasures
• cryptographicSecurityStandards
• providerContactInformation
• minimumSize
• maximumSize
• storageConfiguration
• lifetimeManagement
• versioning
• storageConsistency
• dataViews
• multipleViews

[anjastrunk]

Taking, what I figured out in my last comments, the following attributes must be generated:

Gaia-X Attribute	OpenStack Attribute
providedBy (mandatory)	Gaia-X expects a link to Gaia-X Credential of CSP as legal person. We already implemented this in PR #55 and can reuse code.
serviceOfferingTermsAndConditions (mandatory)	Resolvable URL to service's terms and conditions. Not discoverable, we use config entry. We already implemented this in PR #55 and can reuse code.
servicePolicy (mandatory)	Not discoverable. We already implemented this in PR #55 and can reuse code.
dataAccountExport (mandatory)	Not discoverable. We already implemented this in PR #55 and can reuse code.
storageConfiguration.storageEncryption	If description contains [scs:encrypted] If description does not contain [scs:encrypted] Problem: class [Encryption]() expects two attributes cipher and keyManagement, which are not discoverable and we have to think about how to set these attributes, manually.
storageConfiguration.redundacyMechanism	Gaia-X Ontology is a bit messed up with respect to block storage offering, which makes it hard to create valid Gaia-X Credentials. I cleaned it up a bit and added missing features. For detail please visit PR#276

[anjastrunk]

Undiscoverability Gaia-X mandatory attributes

Gaia-X models encryption with class Encryption, which has two mandatory attributes, which are not discoverable from cloud. These attributes must be set manually. We have two possibilities to do that:

1. Put undiscoverable attributes in generator's configuration file and write them to Gaia-X Credential of block storage during generation time.
2. Put undiscoverable in separate Gaia-X Credential and them Gaia-X Credential of block storage using linked data principles

Both proposals have different pros and cons. The first proposal is easy to implement, but no scalable as it will blow up configuration file. The second one, requires a more complex implementation, but will be scalable. As we want to support linked data principles, see #73, we decided to go for proposal 2.

[anjastrunk]

Use linked-data principles to add undiscoverable (mandatory) attributes

Linked data offers a possibility spread knowledge about subject in different files. We use this feature to provide undiscoverable (mandatory) attributes. Assume we have an OpenStack volume type, which is encrypted. Encryption itself, can be discovered but not the mandatory attributes cipher and ''keyManagement`. They must be added by CSP manually.