ui lb algorithm from capability - #134
Open
msinhore wants to merge 2 commits into
Open
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
Before this change, both the public LB form (LoadBalancing.vue) and the
internal LB form (network.js Internal LB action) hard-coded the algorithm
dropdown to ['source', 'roundrobin', 'leastconn']. Every Lb provider got the
same three options regardless of what the provider actually supported, so a
user could pick "leastconn" against, e.g., the OVN provider, only to get the
rule rejected later by validateLBRule. The capability is already declared
(NetworkElement.getCapabilities() -> Service.Lb -> Capability.SupportedLBAlgorithms)
and surfaced by listNetworks - we just weren't reading it.
LoadBalancing.vue (public LB - the create modal and the edit-rule modal):
- Replaces the three static <a-select-option>s with a v-for over a new
`supportedAlgorithms` data field defaulting to the legacy
['roundrobin', 'leastconn', 'source'] (so providers/networks that don't
declare the capability behave exactly as before).
- Adds fetchLbCapabilities() (called from fetchData) which:
* resolves the network id from resource.associatednetworkid or
resource.networkid,
* looks up the network via listNetworks,
* walks service[name=Lb].capability[name=SupportedLbAlgorithms] and
splits the CSV into the dropdown list,
* snaps newRule.algorithm to the first supported value if the previous
default falls outside the new set,
* swallows any error so we never break the page on a backend hiccup.
listNetworks is the right endpoint here. listNetworkOfferings hard-codes
only SupportedLBIsolation/ElasticLb/InlineMode/VmAutoScaling for the Lb
service in createNetworkOfferingResponse, while createNetworkResponse
walks the live provider's getCapabilities() and exposes everything we
declared - including SupportedLbAlgorithms.
network.js (internal LB action):
- Leaves the static option list in place but flags the spot with a TODO.
Driving this declaratively requires AutogenView to support an async or
function-valued `mapping[field].options`, which is a framework-level
change and out of scope for this UI patch. A follow-up can convert the
declarative mapping to a SFC and adopt the same approach as the public
LB form.
The change is provider-agnostic: it benefits every Lb provider that
correctly declares SupportedLBAlgorithms. OVN gets {roundrobin, source};
VirtualRouter keeps {roundrobin, leastconn, source}; Netscaler/F5/etc.
will reflect whatever they declare, and providers without the capability
fall back to the legacy three.
This commit is intentionally self-contained on top of the OVN plugin work
so it can be cherry-picked into a dedicated upstream PR.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Extends the data-driven LB algorithm dropdown previously added in
LoadBalancing.vue (public-IP LB form) to the two remaining places
where the capability was still hard-coded as
['source', 'roundrobin', 'leastconn']:
- VpcTiersTab.vue: the "Add Internal LB" modal accessible from the
VPC details page. The dropdown now follows the capability declared
by the selected tier's Lb provider, looked up via listNetworks at
the moment the modal opens (handleAddInternalLB ->
fetchLbCapabilitiesForNetwork). Falls back to the legacy three when
the lookup fails or the provider does not declare the capability,
so providers without it behave exactly as before.
- AutoScaleLoadBalancing.vue: the "Edit rule" modal on a VPC public
AutoScale LB. Same pattern - openEditRuleModal ->
fetchLbCapabilitiesForRule reads the capability from the rule's
tier network and narrows the dropdown to whatever the provider
actually accepts.
LoadBalancing.vue: keeps its existing per-network lookup but adds a
fallback for the VPC case. When the public IP record exposes only
vpcid (the IP has not been associated to a specific tier yet because
no rule exists), the helper now picks any Lb-enabled tier of the VPC
via listNetworks(vpcid=..., supportedservices=Lb) and reads the
capability from that tier. Every tier of the same VPC uses the same
Lb provider, so the answer is provider-uniform.
The change is provider-agnostic - any Lb provider that correctly
declares Service.Lb -> Capability.SupportedLBAlgorithms benefits.
The OVN provider exposes {roundrobin, source}, VirtualRouter keeps
{roundrobin, leastconn, source}, NetScaler / F5 / etc. will reflect
whatever they declare, and providers without the capability fall
back to the legacy three. listNetworks remains the right endpoint
because the offering response only emits a fixed subset of Lb
capabilities while createNetworkResponse walks the live provider's
getCapabilities() and surfaces SupportedLbAlgorithms verbatim.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The LB algorithm dropdown in every Load Balancer form was hard-coded to
['source', 'roundrobin', 'leastconn'] regardless of what the network's Lb
provider actually supports. A user could pick leastconn against a provider
that does not implement it (e.g. a third-party or future provider that
declares only a subset), and the rule would only be rejected later by
validateLBRule on the backend.
The capability is already declared by every NetworkElement via
getCapabilities() -> Service.Lb -> Capability.SupportedLBAlgorithms
and surfaced by listNetworks (createNetworkResponse walks the live
provider's capabilities verbatim). The UI just was not reading it.
This PR makes every LB algorithm dropdown data-driven from that capability,
across the four places where the list was hard-coded:
the VPC details page.
VPC public AutoScale LB.
a TODO; converting it requires AutogenView to support async/function-
valued mapping[field].options, which is a framework-level change out of
scope here).
How it works
Each form gains a supportedAlgorithms data field (default
['roundrobin', 'leastconn', 'source'] — the legacy list) and a
fetchLbCapabilities*() helper that:
resource.networkid / the selected tier.
splits the CSV into the dropdown list.
previous default falls outside the new set.
that do not declare the capability behave exactly as before.
listNetworks is used (not listNetworkOfferings) because the offering
response hard-codes only SupportedLBIsolation / ElasticLb / InlineMode / VmAutoScaling for the Lb service, whereas createNetworkResponse exposes
the full provider capability set including SupportedLbAlgorithms.
Backwards compatibility
Provider-agnostic and fully backwards-compatible:
Types of changes
How Has This Been Tested?
UI exercised against a 4.23-dev environment with two Lb providers declaring
different SupportedLBAlgorithms sets:
Verified that backend errors on listNetworks (simulated by stopping the management server briefly) do not break the dropdown — it falls back to the legacy three and the form remains usable.