From 57787f9402ab0a0cc5b3ac7460678c1ec5e5dcef 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 ef00863ce91c..03860d7e25e9 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 cebc2c926e9349299c1a08b46cb034bc8d5b4b70 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 03860d7e25e9..b19140faa60a 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 97d0b2b127524cd929d959166eff0bc3be1a523d 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 b19140faa60a..c14ca23d7917 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 4153f43d2441b86d4fccf28dfb14796f94a3b2bf 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 c14ca23d7917..4a8ea6b13e46 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 51a36521dc1156248d525183ac3177fe3b4841a5 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 4a8ea6b13e46..67863aa0b1b9 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.