* on 28.03 native service version discovery request to https://as.eu-de.otc.t-systems.com/autoscaling-api/ caused timeout. AS service is temporarily disabled

* KMS service version discovery is broken. On https://kms.eu-de.otc.t-systems.com/ it returns
  {"versions": [{"status": "CURRENT", "id": "v1.0", "links": [{"href": "https://rts.eu-de.otc.t-systems.com/v1/", "rel": "self"}]}]}
  In the keystoneauth1 it results to get_endpoint=https://kms.eu-de.otc.t-systems.com/v1 (instead of V1.0). Detailed investigation is expensive, therefore aborted

* KMS does not follow REST, everything is POST with different URLs and not even json['action']

* KMS is conceptually far away from Barbican

* KSM API Doc: This API allows you to create a plaintext-free DEK, that is, the returned result of this API includes `only the plaintext` of the DEK.

* KMS: purpose of KMS is not preciese. Attributes change their names/meaning depending on call

* KMS: encryption_context is described to be string, in reality dict is expected

* KMS: max_length is always expected to be exactly max. Make no sence as a param

* KMS: list CMK filter by key_state not working as documented

* KMS: format of the timestamp is unknown

* KMS: no way to get response in english

* CCE: required header applicytion/type also for GET

* CCE: cluster UUID is hidden in a inline metadata structure, making it hard to address it without dirty hacks.
  Apis are jumping throught this structure in anti-rest pattern

* CCE: attribute naming: metadata.uuid vs metadata.uid

* CCE: undocumented properties of the cluster.spec field (i.e. `cidr`)

* Inconsistent naming between services (AS:create_time, KMS:creation_date, CCE:createAt)

* Inconsistent error message structure between services (i.e. KMS vs RDS). This prohibits code generalization

* DCS: Since Redis 3.0.7 (only available in DCS) lots of critical issues (incl. security and possible data corruption), online memory defrag, less mem usage were fixed

* MRS: Inconsistent naming between services ( data_processing-mrs ),  initial plugin not visible in command list


* DCS: in OS DCS is part of Trove. The API is same. In the DCS API is similar to RDS, but not easy mappable

* CCE: far away from Magnum

* OBS has storage class on Bucket level, but in AWS and all corresponding tools (also s3cmd, s4cmd, Boto) it is on the Object level

* No custom service supports proper version discovery. Leads to error messages in the OSC tool and execution delays

* DNS: nothing supports private zone (ansible, heat, ~terraform, SDK/CLI). Very hard to cover that everywhere

* DNS: Zone transfer feature of API V2 is not present. Modern Designateclient is not getting clear with response of designate

* HEAT: very old level, blocking many OpenSource projects, including i.e. ansible-openshift, RedhatDNS.

* HEAT: (to be doublechecked) template version check is likely not done, since features of later templates with older version header are passing validation (in the ranges of supported versions)

* HEAT: validate return ok, doesn't mean create will pass (validation errors i.e. template version doesn't match, condition on a resource level was also added on newton)

* HEAT: not all CLI calls return result

* Shade/Ansible: enabling SNAT through Ansible not possible, since upstream expects default as true and sends only false if set (shade:_build_external_gateway_info)

* Shade/Ansible: only able to pass SYS volume size if boot_from_volume=True (default=false)

* Shade/Ansible: on a play retry port in the subnet changes if exists (change IP) and corrupts connection

* VPC!: VPC uses network wrapped subnets. Simple net with multiple subnets is not properly visible in OTC (in VPCs list subnet count includes all subnets, but in VPC show subnets are missing)

* EVS: volume type list --long returns changing results

* Ansible: no support for load balancer

* HEAT: Not possible to rely on mountpoint of the OS::Cinder::VolumeAttachment

* HEAT: block_device_mapping_v2 with >1 device fails

* Server create through HEAT fails with volume (SYS) not found (disappear) with >1 mapping (=1 everything ok).
    - fedora atomic image
    - block_device_mapping_v2 with multiple entries
    - delete_on_terminate=true, with "false" loop with server is being constantly recreated (state faulty)
    - all devices are present and attached while server is in state creating
  Not possible to remove stack/sg/subnet, since Neutron claims in use.
  Reason: port in the subnet is not released (net might be unattached from router, so not even visible in GUI)

* SDK LBaaS: pool.healthmonitor_id according to ref api (and in OTC), but in the SDK it is health_monitor_ids (list). Some other attributes missing
  - pool_member operating_status missing
* SDK LBaaS HM: max_retries_down missing (optional and not present in OTC)


* General: at least on example of ULB LIST allows filtering, but it is not documented
