From 3f991e2ff3fe3c942c0fe5cf094c94408084eaca Mon Sep 17 00:00:00 2001 From: Luis Tomas Bolivar Date: Fri, 24 Apr 2020 18:44:03 +0200 Subject: [PATCH 1/5] Add information about octavia upgrades impact on Kuryr SDN --- ...tallation-osp-kuryr-known-limitations.adoc | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/modules/installation-osp-kuryr-known-limitations.adoc b/modules/installation-osp-kuryr-known-limitations.adoc index 191516b54d5f..a7489ee34bd2 100644 --- a/modules/installation-osp-kuryr-known-limitations.adoc +++ b/modules/installation-osp-kuryr-known-limitations.adoc @@ -59,3 +59,43 @@ In Go versions 1.13 and later, TCP is used automatically if DNS resolution using musl-based containers, including Alpine-based containers, do not support the `use-vc` option. ==== +[discrete] +[id="openstack-upgrade-limitations_{context}"] +== {rh-openstack} upgrade limitations + +There are limitations to consider when using Kuryr SDN during the {rh-openstack} +upgrades process, in relation to Octavia and its load balancers updates. + +When OpenStack is upgraded, besides the expected Octavia's API changes, there is +a need for updating the amphora image that will be used for the load balancer +VMs. However, there is two options for the existing load balancer VMs: + +* {rh-openstack} operator handles the image upgrade of the existing load balancer VMs by triggering a link:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/networking_guide/sec-octavia#update-running-amphora-instances[Load Balancer failover] action per existing Load Balancer. +* {rh-openstack} operator does nothing related to existing load balancers VMs +and leaves the update for the users. + +Both actions have implications when using Kuryr SDN: +* If the {rh-openstack} operator handles the upgrade, there may be small +downtimes during the Octavia loadbalancers failover affecting the related +Services. + +* If the {rh-openstack} operator does not handle the upgrade of existing Load +Balancer VMs, new features enabled by Octavia API (e.g., UDP listeners) won't +work on the existing load balancers. Given that UDP services were not supported +in {rh-openstack} versions earlier than 16, if the {rh-openstack} operator does +not handle the load balancers upgrade, users would need to recreate their +Services if they want to expose UDP ports, instead of modifying the current +service specification to add UDP ports. + +[IMPORTANT] +==== +Due to the above limitations, the cluster network operator triggers the recreation +of the dns service as soon as the new Octavia version that supports UDP load +balancing is detected. This is done to ensure a new dns-default loadbalancer +is created with support for UDP loadbalancing. +This allows the removal of the admission webhook deployed for Kuryr to ensure +dns resolution was forced through TCP instead of UDP. +Note this causes downtime (around 1 minute) on the dns resolution service +while the loadbalancer is being recreated. +==== + From 922542b9379b352d98553135182ba1bcd5f19ce8 Mon Sep 17 00:00:00 2001 From: Max Bridges Date: Fri, 29 May 2020 11:29:45 -0400 Subject: [PATCH 2/5] First editing pass --- ...tallation-osp-kuryr-known-limitations.adoc | 77 +++++++++++-------- 1 file changed, 46 insertions(+), 31 deletions(-) diff --git a/modules/installation-osp-kuryr-known-limitations.adoc b/modules/installation-osp-kuryr-known-limitations.adoc index a7489ee34bd2..905613feba9f 100644 --- a/modules/installation-osp-kuryr-known-limitations.adoc +++ b/modules/installation-osp-kuryr-known-limitations.adoc @@ -63,39 +63,54 @@ musl-based containers, including Alpine-based containers, do not support the `us [id="openstack-upgrade-limitations_{context}"] == {rh-openstack} upgrade limitations -There are limitations to consider when using Kuryr SDN during the {rh-openstack} -upgrades process, in relation to Octavia and its load balancers updates. - -When OpenStack is upgraded, besides the expected Octavia's API changes, there is -a need for updating the amphora image that will be used for the load balancer -VMs. However, there is two options for the existing load balancer VMs: - -* {rh-openstack} operator handles the image upgrade of the existing load balancer VMs by triggering a link:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/networking_guide/sec-octavia#update-running-amphora-instances[Load Balancer failover] action per existing Load Balancer. -* {rh-openstack} operator does nothing related to existing load balancers VMs -and leaves the update for the users. - -Both actions have implications when using Kuryr SDN: -* If the {rh-openstack} operator handles the upgrade, there may be small -downtimes during the Octavia loadbalancers failover affecting the related -Services. - -* If the {rh-openstack} operator does not handle the upgrade of existing Load -Balancer VMs, new features enabled by Octavia API (e.g., UDP listeners) won't -work on the existing load balancers. Given that UDP services were not supported -in {rh-openstack} versions earlier than 16, if the {rh-openstack} operator does -not handle the load balancers upgrade, users would need to recreate their -Services if they want to expose UDP ports, instead of modifying the current -service specification to add UDP ports. +During the {rh-openstack} upgrade process, two of the things that are relevant to a Kuryr deployment are: + +* Changes to the Octavia API. + +* An upgrade to the Amphora image used for load balancers might be required. + +You can address API changes on an individual basis. + +If the Amphora image is upgraded, the {rh-openstack} operator can handle existing load balancer VMs in two ways: + +* Upgrade each VM by triggering a triggering a link:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/networking_guide/sec-octavia#update-running-amphora-instances[Load Balancer failover]. + +* Leave responsibility for upgrading the VMs to users. + +If the operator takes the first option, there might be short downtimes during failovers. + +If the operator takes the second option, the existing load balancers will not support upgraded Octavia +API features, like UDP listeners. In this case, users must recreate their Services to use these features. + [IMPORTANT] ==== -Due to the above limitations, the cluster network operator triggers the recreation -of the dns service as soon as the new Octavia version that supports UDP load -balancing is detected. This is done to ensure a new dns-default loadbalancer -is created with support for UDP loadbalancing. -This allows the removal of the admission webhook deployed for Kuryr to ensure -dns resolution was forced through TCP instead of UDP. -Note this causes downtime (around 1 minute) on the dns resolution service -while the loadbalancer is being recreated. +If {product-title} detects a new Octavia version that supports UDP load balancing, it recreates the DNS Service automatically. The Service recreation ensures that the Service default supports UDP load balancing. + +The recreation causes the DNS Service approximately one minute of downtime. ==== +// There are limitations to consider when using Kuryr SDN during the {rh-openstack} +// upgrades process, in relation to Octavia and its load balancers updates. + +// When OpenStack is upgraded, besides the expected Octavia's API changes, there is +// a need for updating the amphora image that will be used for the load balancer +// VMs. However, there is two options for the existing load balancer VMs: + +// * {rh-openstack} operator handles the image upgrade of the existing load balancer VMs by triggering a link:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/networking_guide/sec-octavia#update-running-amphora-instances[Load Balancer failover] action per existing Load Balancer. +// * {rh-openstack} operator does nothing related to existing load balancers VMs +// and leaves the update for the users. + +// Both actions have implications when using Kuryr SDN: +// * If the {rh-openstack} operator handles the upgrade, there may be small +// downtimes during the Octavia loadbalancers failover affecting the related +// Services. + +// * If the {rh-openstack} operator does not handle the upgrade of existing Load +// Balancer VMs, new features enabled by Octavia API (e.g., UDP listeners) won't +// work on the existing load balancers. Given that UDP services were not supported +// in {rh-openstack} versions earlier than 16, if the {rh-openstack} operator does +// not handle the load balancers upgrade, users would need to recreate their +// Services if they want to expose UDP ports, instead of modifying the current +// service specification to add UDP ports. + From 6125ae66abc272e2f79a149cd7e7f4f6457e34e3 Mon Sep 17 00:00:00 2001 From: Max Bridges Date: Tue, 9 Jun 2020 07:41:37 -0400 Subject: [PATCH 3/5] Deleting comment block --- ...tallation-osp-kuryr-known-limitations.adoc | 31 ++----------------- 1 file changed, 3 insertions(+), 28 deletions(-) diff --git a/modules/installation-osp-kuryr-known-limitations.adoc b/modules/installation-osp-kuryr-known-limitations.adoc index 905613feba9f..064370c6f616 100644 --- a/modules/installation-osp-kuryr-known-limitations.adoc +++ b/modules/installation-osp-kuryr-known-limitations.adoc @@ -63,9 +63,9 @@ musl-based containers, including Alpine-based containers, do not support the `us [id="openstack-upgrade-limitations_{context}"] == {rh-openstack} upgrade limitations -During the {rh-openstack} upgrade process, two of the things that are relevant to a Kuryr deployment are: +During the {rh-openstack} upgrade process, two changes that are relevant to a Kuryr deployment are: -* Changes to the Octavia API. +* Updates to the Octavia API. * An upgrade to the Amphora image used for load balancers might be required. @@ -88,29 +88,4 @@ API features, like UDP listeners. In this case, users must recreate their Servic If {product-title} detects a new Octavia version that supports UDP load balancing, it recreates the DNS Service automatically. The Service recreation ensures that the Service default supports UDP load balancing. The recreation causes the DNS Service approximately one minute of downtime. -==== - -// There are limitations to consider when using Kuryr SDN during the {rh-openstack} -// upgrades process, in relation to Octavia and its load balancers updates. - -// When OpenStack is upgraded, besides the expected Octavia's API changes, there is -// a need for updating the amphora image that will be used for the load balancer -// VMs. However, there is two options for the existing load balancer VMs: - -// * {rh-openstack} operator handles the image upgrade of the existing load balancer VMs by triggering a link:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/networking_guide/sec-octavia#update-running-amphora-instances[Load Balancer failover] action per existing Load Balancer. -// * {rh-openstack} operator does nothing related to existing load balancers VMs -// and leaves the update for the users. - -// Both actions have implications when using Kuryr SDN: -// * If the {rh-openstack} operator handles the upgrade, there may be small -// downtimes during the Octavia loadbalancers failover affecting the related -// Services. - -// * If the {rh-openstack} operator does not handle the upgrade of existing Load -// Balancer VMs, new features enabled by Octavia API (e.g., UDP listeners) won't -// work on the existing load balancers. Given that UDP services were not supported -// in {rh-openstack} versions earlier than 16, if the {rh-openstack} operator does -// not handle the load balancers upgrade, users would need to recreate their -// Services if they want to expose UDP ports, instead of modifying the current -// service specification to add UDP ports. - +==== \ No newline at end of file From 11c0f25fcf8ca0076e5aa2c52d10e08c23ec8416 Mon Sep 17 00:00:00 2001 From: Max Bridges Date: Tue, 9 Jun 2020 07:43:01 -0400 Subject: [PATCH 4/5] fixup! Deleting comment block --- modules/installation-osp-kuryr-known-limitations.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/installation-osp-kuryr-known-limitations.adoc b/modules/installation-osp-kuryr-known-limitations.adoc index 064370c6f616..759bbc87fee2 100644 --- a/modules/installation-osp-kuryr-known-limitations.adoc +++ b/modules/installation-osp-kuryr-known-limitations.adoc @@ -63,7 +63,7 @@ musl-based containers, including Alpine-based containers, do not support the `us [id="openstack-upgrade-limitations_{context}"] == {rh-openstack} upgrade limitations -During the {rh-openstack} upgrade process, two changes that are relevant to a Kuryr deployment are: +During the {rh-openstack} upgrade process, two changes that can impact Kuryr deployments are: * Updates to the Octavia API. From c682def311da7478be1bc8c07ea0d23bd460acca Mon Sep 17 00:00:00 2001 From: Max Bridges Date: Tue, 9 Jun 2020 08:58:26 -0400 Subject: [PATCH 5/5] fixup! Deleting comment block --- modules/installation-osp-kuryr-known-limitations.adoc | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/modules/installation-osp-kuryr-known-limitations.adoc b/modules/installation-osp-kuryr-known-limitations.adoc index 759bbc87fee2..17aa69bc6b19 100644 --- a/modules/installation-osp-kuryr-known-limitations.adoc +++ b/modules/installation-osp-kuryr-known-limitations.adoc @@ -63,11 +63,7 @@ musl-based containers, including Alpine-based containers, do not support the `us [id="openstack-upgrade-limitations_{context}"] == {rh-openstack} upgrade limitations -During the {rh-openstack} upgrade process, two changes that can impact Kuryr deployments are: - -* Updates to the Octavia API. - -* An upgrade to the Amphora image used for load balancers might be required. +As a result of the {rh-openstack} upgrade process, the Octavia API might be changed, and upgrades to the Amphora images that are used for load balancers might be required. You can address API changes on an individual basis.