fix: [M3-9156] - Linode Config Dialog misrepresenting primary interface

[bnussman-akamai]

Description 📝

• The Linode Config dialog is misrepresenting what is actually the default network interface
• This PR aims to fix the Primary Interface being misrepresented

How "Primary Interface" works ❓

• If an interface is primary we know that's the primary
• If the API response returns an empty array "interfaces": [], under the hood, a public interface eth0 is inherently configured on the Linode. This interface will be primary.
• If a config has interfaces, but none of them are marked primary: true, then the first interface in the list that’s not a VLAN will be the primary interface

Preview 📷

Before	After

How to test 🧪

• Test various network interface variations (try different combinations of VPC, VLAN, Public Internet) in the LInode Config Dialog
  • Be sure to test create and edit
  • Verify the logic explained in How "Primary Interface" works above always remains true
• Verify the Linode Create flow's network interfaces still work correctly
• Verify that for the VPC Subnet Linode table row, the unrecommended config notice is consistent with Linode config dialog's unrecommended config notice

Author Checklists

As an Author, to speed up the review process, I considered 🤔

👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support

• I have read and considered all applicable items listed above.

As an Author, before moving this PR from Draft to Open, I confirmed ✅

• All unit tests are passing
• TypeScript compilation succeeded without errors
• Code passes all linting rules

[github-actions]

Coverage Report: ✅
Base Coverage: 86.69%
Current Coverage: 86.69%

[dwiley-akamai]

I understand why we've done this historically for simple linodes that only have the implicit public interface (basically just to reduce confusion for users), but it does feel a bit odd in the case where there are public, VLAN, and VPC interfaces, none of which are explicitly primary.

I wonder if it'd be better to display "None" for every case other than when there's only an implicit public interface and when there's an explicit primary interface 🤔 Do we make things clearer by not matching more closely what the API has?

[bnussman-akamai]

I wonder if it'd be better to display "None" for every case other than when there's only an implicit public interface and when there's an explicit primary interface

Just to make sure I understand: Are you suggesting we show the Primary Interface as None unless one is explicitly set? I do like this idea because it more closely aligns with the API.

when there's only an implicit public interface and when there's an explicit primary interface

What if there is an implicit primary VPC interface? (I think this is possible)

I think both approaches are fine. Whichever route we go with, I feel like we should make the "Primary Interface" field show exactly what the API returns or the derived implicit/explicit primary interface. Not something in the middle

[coliu-akamai]

hmm that's a good point 🤔

fwiw for the linode configs I've checked so far, this PR's current behavior matches what's specified in admin - this consistency could be helpful for customer support specialists when they're trying to answer tickets

[bnussman-akamai]

I guess the main upside to the current approach is that the user will have a clear indication of the "primary" interface being used under the hood without needing to reference documentation. I do like the idea of more closely aligning with the API response but I'm not sure what UX difference that could make

[coliu-akamai]

ohh one thought I just had though - with this PR if we create a linode via the api with a single interface, vpc, that is not specified as primary, in the UI there's an inconsistency:

• In the linode config dialog, there will be no 'config unrecommended notice'
• In the subnet table there is one:
  

here, aligning with the API could make more sense so that people know their config isn't explicitly the primary one?

[coliu-akamai]

added bonus, using your getPrimaryInterfaceIndex method for this notice would take care of the issue mentioned in this PR about existing configs 👀

This does not resolve the unrecommended config notice for already existing Linodes, just for newly created ones. Customers with this notice on their Linode will need to manually edit their configs to resolve it.

[bnussman-akamai]

Yeah, that would be awesome if we could reuse the getPrimaryInterfaceIndex logic there. Want to push that change @coliu-akamai ?

[coliu-akamai]

can do! i'm gonna test a bit more stuff just to make sure first (it seems p good so far tho 🤞)

[dwiley-akamai]

I wonder if it'd be better to display "None" for every case other than when there's only an implicit public interface and when there's an explicit primary interface

Just to make sure I understand: Are you suggesting we show the Primary Interface as None unless one is explicitly set? I do like this idea because it more closely aligns with the API.

when there's only an implicit public interface and when there's an explicit primary interface

What if there is an implicit primary VPC interface? (I think this is possible)

I think both approaches are fine. Whichever route we go with, I feel like we should make the "Primary Interface" field show exactly what the API returns or the derived implicit/explicit primary interface. Not something in the middle

@bnussman-akamai Yup that's basically what I was suggesting.

I'm seeing now though that the API docs do say "If you haven't specifically set a primary, the first non-vlan type interface is automatically treated as the primary." That makes me feel more comfortable with the current approach in this PR

[coliu-akamai]

just pushed something up - the code I had above did not fully work, but I think what I have now does, albeit could maybe use some cleanup

[bnussman-akamai]

This is the only part I'm not 100% sure about. We should just double check this logic and make sure this doesn't prevent the user from doing what they need to do.

The idea here is that Linode configs that have a VPC and/or Public interface will always have a primary interface (could be explicit or implicit) but the user should be able to have No Primary Interface if they just have a VLAN interface

[dwiley-akamai]

This seems to work as intended from my testing; when there is a VPC or Public interface, the Primary Interface field is not clearable. When there isn't, the Primary Interface field becomes clearable.

[coliu-akamai]

✅ only vlan interface(s) (tested 1-3 vlan only interfaces) - primary interface select defaults to null and is clearable
✅ trying to set a vlan interface as primary leads to an error
✅ if there is either a public or vpc (or both) interfaces, the select is not clearable (and defaults to first non vlan interface)
✅ interface combinations - tested implicit primary interfaces for following combinations

• no interfaces (default public) ✅
• vlan only ✅
• vpc only ✅
• public only ✅
• vpc, vlan ✅ (and vice versa )
• vpc, public ✅ (and vice versa )
• public, vlan ✅ (and vice versa)
• combos of three ✅

✅ confirm subnet linode row notice
✅ creating linode still works

✅ editing a config
✅ creating a config

❓ when creating a new config, not including VLAN interfaces - if I don't change the default selected primary interface, the primary field doesn't get populated in the payload (and the resulting config is not marked as primary).
❓ similarly, when editing a config, if I start with no interface explicitly marked as primary, and just click save w/o changes, no primary: true field will be populated for the implicitly primary interface

Unsure if these are considered blockers though, since it doesn't affect any of the interface's/config functionality (an implicit primary still exists). However, since I'm clicking the 'Create/Save Changes' button, ig I would expect the primary field to be explicitly updated + this is a difference in behavior than prod

Create Config example - On prod, the interface payload for the same actions as in the video is

{
  "ip_ranges": [],
  "ipv4": {
    "nat_1_1": "any"
  },
  "purpose": "vpc",
  "subnet_id": 125165,
  "vpc_id": 130162,
  "primary": true
}

Screen.Recording.2025-01-22.at.5.09.29.PM.mov

[linode-gh-bot]

Cloud Manager UI test results

🎉 475 passing tests on test run #16 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
0 Failing	475 Passing	2 Skipped	92m 4s

[coliu-akamai]

honestly now that I think about it, it's like having to set an explicit primary field no longer feels necessary, just based on how there's no visual or interface functionality difference for the two ❓ I had above. If I hadn't looked at the network requests, I wouldn't have realized those interfaces weren't being explicitly marked primary :o

[dwiley-akamai]

Code review ✅

Tested/verified the following:

• Create new Linode and assign it to a VPC — VPC interface is still primary ✅
• Create new Linode and attach a VLAN — public interface in eth0 and VLAN in eth1, no primary ✅
• Edit & save config (no interface currently set to primary) w/o explicitly setting Primary Interface — upon opening dialog again, it consistently reflects the first non-VLAN interface ✅
• Edit config that has multiple interfaces, remove all but the VLAN interface — Primary Interface becomes “None” and is not clearable ✅
• Get an error when you try to set a VLAN as the primary interface ✅
• Unrecommended Config notice consistency b/w Linode Config dialog & VPC Subnet Linode table row ✅

[dwiley-akamai]

Suggested change

	it('does not display an unrecommended config notice for a Linode with an implicit primary VPC', () => {
	it('does not display an unrecommended config notice for a Linode with an implicit primary VPC interface', () => {

[dwiley-akamai]

This seems to work as intended from my testing; when there is a VPC or Public interface, the Primary Interface field is not clearable. When there isn't, the Primary Interface field becomes clearable.

[bnussman-akamai]

I think I see what you mean @coliu-akamai

Are you saying we should make Cloud Manager pass primary: true (for the implicit primary) so that the backend actually marks the interface as primary?

[coliu-akamai]

@bnussman-akamai yep, sorry I wasn't clear 😅

ig it's a nice to have and would match prod's behavior, but it no longer feels as necessary now that we can show the implicit primary interface - will approve this PR!

[bnussman-akamai]

I do agree that it might be preferable to make Cloud Manger explicitly pass primary: true but I don't think it matters from a functionality perspective 🤔 It should be a somewhat easy change if we decide to make it. I will try it out 👀

[bnussman-akamai]

Actually, I might feel okay with how things are currently. I think it's okay if we just abide by how the API works and not try to make Cloud Manager forcefully set a primary. I could go either way but I think what we have is acceptable 😵‍💫

[coliu-akamai]

makes sense, sounds good to me 🚀

[cypress]

Cloud Manager E2E    Run #7108

Run Properties:   Passed #7108  •  77b9661efa: fix: [M3-9156] - Linode Config Dialog misrepresenting primary interface (#11542)

Project	Cloud Manager E2E
Branch Review	develop
Run status	Passed #7108
Run duration	28m 12s
Commit	77b9661efa: fix: [M3-9156] - Linode Config Dialog misrepresenting primary interface (#11542)
Committer	Banks Nussman
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	1
Pending	2
Skipped	0
Passing	476
View all changes introduced in this branch ↗︎