☂️-Issue for "Support Open Telekom Cloud (OTC)"

[timuthy]

How to categorize this issue?

/area control-plane
/area os
/kind enhancement
/priority normal
/platform openstack

Open Telekom Cloud (OTC) is mostly based on OpenStack (ref) and using this OpenStack provider extension seems as the quickest and a preferable way to support OTC.

Identified issues:

🚧 Egress traffic for worker machines not possible (#165).

❔ VM root disk size is not configurable.

error message: {"badRequest": {"message": "Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid.", "code": 400}}

❔ LoadBalancers can't be created via K8s services: kubernetes/cloud-provider-openstack#960

---

	Status
✅	completed
🚧	in progress
❔	in clarification
❌	incomplete

[timuthy]

We'll open separate issues/PRs and link them here as soon as we have identified specific requirements for the provider extension.

[shimoza]

I will discuss it with the RnD. In general, if boot_index is set to 0, the system disk size cannot be set and the error you mentioned appears. If boot_index value is non-zero or omitted, VM is getting spawned with two disks:

• system disk size is inherited from the image
• data disk, equal to "volume_size"

some API call examples:
Test 01, Private Image with 40 GB system disk, boot_index is set to non-zero.
{
"server": {
"imageRef": "0a44cb5a-9fcf-49f0-9d32-505102ab5da6",
"flavorRef": "s2.large.2",
"name": "kla02",
"block_device_mapping_v2": [{
"source_type": "image",
"destination_type": "volume",
"uuid": "0a44cb5a-9fcf-49f0-9d32-505102ab5da6",
"delete_on_termination": "False",
"boot_index": "1",
"volume_type": "SAS",
"volume_size": "20"
}],
"security_groups": [{
"name": "sg-anyany"
}],
"networks": [{
"uuid": "66f9f277-da3d-4802-a5ac-ff98cc1308c4"
}],
"key_name": "kla-10491",
"availability_zone": "eu-de-01"
}
}

Result: an ECS with two disks:

• system disk, 40 GB size, inherited from the image
• data disk, the size is equal to "volume_size"

Test 02, Private Image with 40 GB system disk, boot_index = 0:

{
"server": {
"imageRef": "0a44cb5a-9fcf-49f0-9d32-505102ab5da6",
"flavorRef": "s2.large.2",
"name": "kla03",
"block_device_mapping_v2": [{
"source_type": "image",
"destination_type": "volume",
"uuid": "0a44cb5a-9fcf-49f0-9d32-505102ab5da6",
"delete_on_termination": "False",
"boot_index": "0",
"volume_type": "SAS",
"volume_size": "40"
}],
"security_groups": [{
"name": "sg-anyany"
}],
"networks": [{
"uuid": "66f9f277-da3d-4802-a5ac-ff98cc1308c4"
}],
"key_name": "kla-10491",
"availability_zone": "eu-de-01"
}
}

Result:
{
"badRequest": {
"message": "Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid.",
"code": 400
}
}

[r-ising]

Any update on this issue?

[berendt]

They also don't use Octavia for LBaaS.

We are currently clarifying if we can adopt the issue to create an OpenStack based extension for the OTC.

[gtema]

We are currently in progress of getting Octavia API to OTC (something like in few months). There might be still further adoption issues (it's gonna be Octavia API managing OTC LB with their features) but we are clearly moving in this direction and are open for concrete dialog.

[sphr2k]

@gtema I noticed https://github.com/opentelekomcloud-infra/octavia-proxy/ a while ago. Really looking forward to Octavia being supported on OTC. Do you have an ETA for the project?

Also, are you aware of any plans to implement PROXY protocol support for OTC ELB v3? As it is, there is no way to get the actual client IP when using the ELB.

[berendt]

@sphr2k From our side, we plan to address the OTC extension when the Octavia proxy is in place. We won't spend any time on v3, since it is foreseeable that the proxy function will come.

@gtema I would also be interested in the current status. A few months have passed in the meantime.

[gtema]

Yeah, the time passes and things are still under question:

• Octavia proxy as a solution is ready (from SW pov) and deployed for testing (no SLA, no API limits bypassing, etc)
• we struggle to find resources currently to deploy it productively. Actially anybody is able to deploy container locally wherever and use it specifying octavia_endpoint_override in the clouds.yaml (at least this is exactly how we test it now)
• we can theoretically mark it as "beta" without SLA and with potential to face API throttling limits and register it in the service catalog. Here I still need mgmt approval.
• I have no information about proxy support. Neither I have information when elbv3 may become available in the eu-de region

[sphr2k]

@gtema Thanks for the feedback. I tried the proxy locally. Is it also possible to deploy it on K8s? I couldn't find an endpoint override parameter for OpenStack CCM.

[gtema]

It is possible to deploy it on CCE without problems, but yes, absence of endpoint override in cloud provider is am issue

[sphr2k]

@gtema Thanks - so can you give me a hint how to use it on OTC or is it not possible?

[berendt]

A directly usable image is now available at quay.io/osism/otc-octavia-proxy:latest.

We will install the proxy next week and then test whether Gardener with the OTC does now directly work with the OpenStack extension.

[gtema]

Our latest build images are at quay.io/opentelekomcloud/octavia-proxy

[sphr2k]

@berendt Thanks for the hint. What I meant was: is it possible to use Octavia Proxy on Kubernetes with Openstack CCM? How would I tell the CCM to go though the proxy?