| opendevreview | Ghanshyam proposed openstack/octavia master: Update python classifier in setup.cfg https://review.opendev.org/c/openstack/octavia/+/904682 | 09:08 |
|---|---|---|
| opendevreview | Ghanshyam proposed openstack/octavia-dashboard master: Update python classifier in setup.cfg https://review.opendev.org/c/openstack/octavia-dashboard/+/904683 | 09:08 |
| opendevreview | Ghanshyam proposed openstack/octavia-lib master: Update python classifier in setup.cfg https://review.opendev.org/c/openstack/octavia-lib/+/904684 | 09:08 |
| opendevreview | Ghanshyam proposed openstack/python-octaviaclient master: Update python classifier in setup.cfg https://review.opendev.org/c/openstack/python-octaviaclient/+/904685 | 09:08 |
| kevko | Hi, we were upgrading openstack with octavia from version Wallaby to version Xena and we were using provider = octavia (which was in wallaby -> octavia.api.drivers.amphora_driver.v1.driver:AmphoraProviderDriver) BUT in xena provider octavia is changed (octavia.api.drivers.amphora_driver.v2.driver:AmphoraProviderDriver) . Problem is that provider | 12:28 |
| kevko | value is saved in Database, so manipulating with LB stopped work as loadbalancers are v1 but octavia project point provider octavia to v2 .... what we've done was that we patched provider octavia in entrypoints from v2 to v1 .... how to deal with it ... I think THIS IS A BUG ..as default is amphorav2 and octavia has to be backward compatible and | 12:28 |
| kevko | should point to v1 .... | 12:28 |
| kevko | Release note is saying that there is an alias amphorav1 ...but i think this can't work ..or it means that I need to fix provider = octavia to provider = amphorav1 in database ... | 12:29 |
| kevko | So question is, is it bug ? How can I deal with it without entrypoints patch we've made | 12:30 |
| gthiemonge | kevko: hi, it's intentional, the amphorav2 provider is compatible with load balancers created with the amphorav1 provider, the migration from wallaby to xena should be a problem here | 13:00 |
| gthiemonge | amphorav1 and amphorav2 are only drivers that control the life-cycle of the amphorae and not API versions between the control plane and the amphorae. An amphora instance doesn't know what v1 or v2 means | 13:02 |
| kevko | gthiemonge: well, we really faced those issues | 13:03 |
| kevko | gthiemonge: LBs were created with provider octavia ...not amphorav1 | 13:03 |
| kevko | gthiemonge: but between versions octavia provider changed from v1 to v2 | 13:03 |
| kevko | gthiemonge: and we are not using amphorav2 yet ... | 13:04 |
| kevko | and it was a problem | 13:04 |
| kevko | gthiemonge: if i remember correctly ... the problem was also mixed with k8s openstack provider ..which has hardcoded 'octavia' | 13:06 |
| gthiemonge | kevko: in Xena, the amphorav2 provider should be automatically enabled (unless you set enabled_provider_drivers to amphorav1 only | 13:08 |
| kevko | gthiemonge: give me a sec ...i will find cloud provider we used to use | 13:10 |
| kevko | gthiemonge: hmm, we have about 1500 k8s clusters which has openstack cloud provider ...this was probably the reason why we better touched octvia itself then change config of cloud provider from octavia => amphora ... am i right ? | 13:27 |
| kevko | gthiemonge: okay now I understand probably all | 13:31 |
| kevko | gthiemonge: so, what do you think about this ... https://github.com/kubernetes/cloud-provider-openstack/blame/2b17004639bc1d9929ed9e7bb8b20d99f893cd9a/pkg/openstack/openstack.go#L67 | 13:35 |
| kevko | gthiemonge: var supportedLBProvider = []string{"amphora", "octavia", "ovn"} | 13:36 |
| kevko | gthiemonge: cloud provider had amphora (v2), octavia(v1), ovn (ovn) (wallaby) ... and now it is amphora (v2), octavia(v2), ovn (ovn) (xena+) .... can be a problem right ? | 13:37 |
| kevko | gthiemonge: even in put there is not allowed to send provider as cloud-provider does https://github.com/openstack/octavia/blob/6079b9c4cdb336ad485f95cf3fa82520e22105cb/octavia/api/v2/types/load_balancer.py#L133C1-L133C45 | 13:51 |
| kevko | gthiemonge: am i right ? | 13:52 |
| kevko | gthiemonge: also here https://github.com/openstack/octavia/blob/9592b54d594506b3bf72e2e7d356445f137b101d/octavia/api/v2/controllers/load_balancer.py#L714 | 13:52 |
| gthiemonge | looking... | 13:53 |
| gthiemonge | so if lb.provider is amphora or octavia in the DB, Octavia will use amphorav1 in wallaby (because of the alias setup.cfg) or amphorav2 in xena (because of the new alias), it's perfectly fine, even for LBs created with older releases | 13:56 |
| gthiemonge | the only issue you can have is: if lb.provider is amphorav1 (which is not a great idea to have in the DB), amphorav1 may not be enabled in Xena | 13:57 |
| kevko | gthiemonge: check validation of PUT request for change https://github.com/openstack/octavia/blob/6079b9c4cdb336ad485f95cf3fa82520e22105cb/octavia/api/v2/types/load_balancer.py#L133C45-L140 here and as you can see here https://github.com/openstack/octavia/blob/9592b54d594506b3bf72e2e7d356445f137b101d/octavia/api/v2/controllers/load_balancer.py#L714 | 14:03 |
| kevko | ... provider is loaded from DB and code just don't care what is in object from request ..because there it can't be | 14:03 |
| kevko | because it can't pass validation for PUT request | 14:03 |
| kevko | so cloud provider couldn't change the LBs | 14:05 |
| kevko | so ? | 14:05 |
| gthiemonge | kevko: sorry I don't understand the point, does Octavia raise an exception there? | 14:22 |
| kevko | gthiemonge: yep, let me gather some logs .. | 14:23 |
| opendevreview | Lukas Piwowarski proposed openstack/octavia-tempest-plugin master: Add backup member tests https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/897564 | 15:36 |
| opendevreview | Lukas Piwowarski proposed openstack/octavia-tempest-plugin master: Add backup member tests https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/897564 | 15:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!