-
Notifications
You must be signed in to change notification settings - Fork 12
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
endless port+floating-ip allocation (LB for kube-api) seems to happen again #480
Comments
Can the #283 be related? |
Maybe, i have not checked whether we had two unrelated subnets accidently. It might well be that this is a distinct issue as the error message was something like "could not associate floating ip to loadbalancer because the loadbalancer already has a floating ip attached". We could also reproduce the error that attaching a FIP to a loadbalancer fails if it has one already via the horizon dashboard. |
is the complete error message |
The By trying to reproduce this to investigate the cause, there were multiple observations. Generally i think it is related to #283 because it worked fine starting from a clean project (my attempt) but didn't work for @mxmxchere trying to create a cluster in the same project shortly after. Follow up of the current state:
|
As far as I know, it is possible to deploy multiple clusters in the same OpenStack project. I and @matofeder successfully share one OpenStack project. See also #343, where the last missing piece was implemented to fully support this use case.
I think that it is related to inconsistencies with multiple clusters. Personally, most of the time I prefer |
After further investigation, this issue seems to resolve around the Reproduction:I was able to reproduce it by using two separate application credentials and environment files, setting a different prefix but using the same Problem:This looks like a "race condition" where two capo controllers are trying to reconcile the same LB with different FIPs. One of them "wins" by being the first, leaving the second to constantly try to attach "his" FIP to the LB. Options to fix:
As a bonus for the capo controller, there should be a limit on how many attempts are made before aborting, because of the usage of public (and limited) ipv4 addresses. |
We can combine option 1 and 2:
That way behaviour for existing installations is not changed while helping to avoid the resource conflicts. |
#495 is probably also related |
Approach to solve this as discussed in container meeting on 17.08.:
|
This is related to / blocked by the above part of #495 . Once the load balancer name includes the $PREFIX, this issue should be fixed because #506 was implemented to make sure that the prefix is unique. See this comment above for background on why the prefix is necessary / should fix the issue. |
This issue was originally described here #179.
We are currently using openstack capo controller version 0.7.3 with the regiocloud openstack infrastructure and this seems to happen again. The theory that this has something to do with the CA being supplied to the capo-controller-manager is not true (it happened now with the CA being there right from the beginning.)
The text was updated successfully, but these errors were encountered: