| *** yadnesh|away|pto is now known as yadnesh | 03:59 | |
| skraynev | hi. I see, that the last octavia releases use alias "amphora" for "amphorav2" driver. what is the correct way to leave old LBs and other resources on "amphorav1" for now? I ask about it, because as I see my current deployment uses old logic and "amphora" == "amphorav1". Should I patch all resources directly and replace "amphora" on "amphorav1" in DB? As I understand setting "defaul_enable_driver=amphorav1" will not solve it, because | 08:22 |
|---|---|---|
| skraynev | old resources has references on "amphora" driver in DB | 08:22 |
| gthiemonge | skraynev: hi, amphorav1 and amphorav2 are different only on the control plane side, an existing amphora VM can be controlled by either amphorav1 or amphorav2 | 08:25 |
| gthiemonge | so it means that if you upgrade from a version that has amphora==amphorav1 to a version with amphora==amphorav2, it should be really transparent and straightforward | 08:26 |
| gthiemonge | our recommandation is to only use amphorav2, amphorav1 is now deprecated, we will still fix bugs in stable releases but we focus on v2 | 08:27 |
| skraynev | gthiemonge: under control plane do you mean using "jobboard" or something else? regarding updating from "amphorav1" to "amphorav2" - does it mean, that old/existing resources with "amphora" provider in DB will be correctly handled by new logic for "amphorav2"? Do I need to do anything else to update old resources after migration to fresh octavia release with new default? | 08:33 |
| gthiemonge | skraynev: yes, old resources created by v1 will be correctly handled by v2. The resources don't need to be updated, the only thing that changes is the code that controls the resources | 08:36 |
| *** priteau_ is now known as priteau | 08:58 | |
| arddennis | gthiemonge: Hi I would like to discuss patch: | 09:04 |
| arddennis | https://review.opendev.org/c/openstack/octavia/+/558962 I added simple tempest scenario to test multiaz defined in lb flavor https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/868868/1/octavia_tempest_plugin/tests/az_scenario/v2/test_load_balancer.py | 09:04 |
| tweining | gthiemonge, johnsom, rm_work: someone is asking for another review in https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/867810 | 09:05 |
| gthiemonge | arddennis: hi | 09:09 |
| gthiemonge | tweining: ack | 09:09 |
| opendevreview | Denys Mishchenko proposed openstack/octavia-tempest-plugin master: Add test_multiaz_loadbalancer_create scenario https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/868868 | 09:16 |
| opendevreview | Merged openstack/octavia-tempest-plugin master: Make user role logging optional https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/867810 | 11:13 |
| *** yadnesh is now known as yadnesh|away | 15:39 | |
| kurt-octavia | I have a question about whipping up the CA and certs for Octavia/Amphora. When I define the common name, can that be a wildcard? Example: *.openstack.<mysite>.com ???? | 15:52 |
| johnsom | kurt-octavia I am assuming you are talking about the control plane certificates as described here: https://docs.openstack.org/octavia/latest/admin/guides/certificates.html ? | 16:02 |
| johnsom | If so, if you would like to use wild cards as opposed to the actual subject, it should work, but you reduce security in that if one host is compromised you will need to revoke them all. | 16:03 |
| johnsom | If you mean for the listeners, yes, wildcard certs are fully supported. | 16:04 |
| opendevreview | Denys Mishchenko proposed openstack/octavia-tempest-plugin master: Add test_multiaz_loadbalancer_create scenario https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/868868 | 18:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!