-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Kuryr: Add information about amphora to ovn-octavia upgrades #22878
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
maxwelldb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How's this, now, @luis5tb?
| ---- | ||
| <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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nitpicks based on guidelines and don't forget to squash commits. Otherwise, LGTM.
installing/installing_openstack/installing-openstack-installer-kuryr.adoc
Outdated
Show resolved
Hide resolved
|
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.