Kuryr: Add information about amphora to ovn-octavia upgrades#22878
Kuryr: Add information about amphora to ovn-octavia upgrades#22878maxwelldb merged 8 commits intoopenshift:masterfrom
Conversation
This PR describe the steps to performan an amphora to ovn-octavia migration when using Kuryr. This allows to avoid the problem of generating one VM per services when using Kuryr as CNI.
|
https://bugzilla.redhat.com/show_bug.cgi?id=1846862
Not urgent at the moment, as we still need to do the backport to 4.5 (of the support itself) |
|
Thanks! |
|
Note to self: This will probably have to be broken out into its own assembly. NBD, but will require restructuring the PR. |
|
/lgtm upgrade worked perfectly fine following the instructions |
| ---- | ||
| <1> Delete this line. The cluster will regenerate it with `ovn` as the value. | ||
| + | ||
| After making this modification, wait for the `kuryr-controller` and `kuryr-cni` pods to redeploy. This process may take several minutes. |
There was a problem hiding this comment.
this should be "wait until the Cluster Network Operator detects the modification and redeploy the kuryr-controller and kuryr-cnis"
|
@luis5tb Made a few more changes based on your comments. I also moved the topic into the Networking section, as it seems like this task must task place post-installation. Thoughts? http://file.rdu.redhat.com/mbridges/Jul03/octavia-upgrade/networking/load-balancing-openstack.html |
I like the idea of having it as a different section, but not the naming of it. This is specific to Kuryr and ovn-octavia, and it is not mentioned on the title or link. It could be misleading. Perhaps in the same way as there is a section there named "Using SCTP", we can call this one "Using OVN-Octavia loadbalancer with Kuryr SDN" |
|
@luis5tb My thought is to make an OSP load balancing space now, with this topic as the sole section in it. Later, it would also contain more general OSP load balancing information (there's a topic that was pulled a few releases ago that might be fit for inclusion). So, it would end up like: Does that seem sensible? |
/lgtm |
|
@luis5tb: you cannot LGTM your own PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Thanks! @luis5tb Did you work with any QE folks on this who'd know it best and could ack this PR, or should I just mention a bunch of Kuryr QE team folks here? 😁 |
|
Cool. Just need a +1 from him here and it's ready for peer review. |
|
/lgtm |
|
@openshift/team-documentation PTAL. Large change. |
|
New changes are detected. LGTM label has been removed. |
…ft#22878) This PR adds a procedure for upgrading from an amphora to ovn-octavia provider driver when using OCP + Kuryr on OSP. Co-authored-by: Max Bridges <mbridges@redhat.com>
[enterprise-4.5] Kuryr: Add information about amphora to ovn-octavia upgrades (#22878)
This PR describe the steps to performan an amphora to ovn-octavia
migration when using Kuryr. This allows to avoid the problem of
generating one VM per services when using Kuryr as CNI.