vishesh92 opened a new pull request, #104:
URL: https://github.com/apache/cloudstack-kubernetes-provider/pull/104
Fixes #2.
Toggling
`service.beta.kubernetes.io/cloudstack-load-balancer-proxy-protocol` on an
existing LoadBalancer service wedges reconciliation permanently:
```
error creating load balancer rule a192...-tcp-proxy-80: CloudStack API error
537:
The range specified, 80-80, conflicts with rule FirewallRule {...} which has
80-80
```
**Cause:** rule names embed the protocol (`<lb>-<protocol>-<port>`) and
rules are looked
up by name, so a protocol change misses the lookup and tries to *create* a
rule on a port
the old rule still holds. The in-place update was already written but
unreachable — a
name-keyed lookup can never return a rule whose protocol differs from the
one requested.
## Changes
- `findLoadBalancerRule` matches on an exact name, then falls back to
(public IP, IP protocol, public port) — the tuple CloudStack enforces
uniqueness on.
A proxy-protocol toggle now resolves to the existing rule and updates it
in place.
Rules on a stale IP are pruned rather than matched, which used to strand
their
firewall rule.
- Renames the rule via `SetName` so the name stops contradicting its
protocol.
- Reconciles in three phases: resolve, prune, apply. Rules blocking a needed
port are
deleted before the creates, everything else after, so a cleanup failure
can't take a
service down. Blocking is keyed on port alone — `detectRulesConflict`
never exempts
LoadBalancing pairs with differing protocols.
Also fixed:
- Proxy protocol was unusable on VPC tiers, independently of #2:
`updateNetworkACL`
created ACLs with `CSProtocol()` (`tcp-proxy`, which CloudStack rejects)
while
filtering with `IPProtocol()`. Both now use `IPProtocol()`.
- Multi-CIDR services churned every sync — an existing rule's `Cidrlist` was
split on
`" "` while CloudStack returns it comma-separated.
- Startup panicked instead of erroring on a management-server version with
fewer than
three parts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
