feat: [UIE-9181] - DBaaS - Display read-only hostname in connection details tables based on VPC configuration

[smans-akamai]

Description 📝

This pull request is display the Read-only Host field in the connection details tables that appear in the Summary and Networking tabs based on VPC configuration for the database.

• This is a follow up to a previous pull request (feat: [UIE-9181] - DBaaS - Display hostname in summary tables based on VPC configuration and refactor connection details #12939) that updated the Hostname field. It applies the same rendering behavior to this read-only host field.
• The verification steps for these changes are also similar.

Changes 🔄

List any change(s) relevant to the reviewer.

• Updating the logic for the Read-only Host field so that it displays different variations based on the Database Cluster VPC configuration.

Scope 🚢

Upon production release, changes in this PR will be visible to:

• All customers
• Some customers (e.g. in Beta or Limited Availability)
• No customers / Not applicable

Target release date 🗓️

10/21/2025

Preview 📷

Note: The before and after screenshots in each scenario show the Connection details tables in the Database Details Summary and Networking tabs.

Scenario 1: Database Cluster with No VPC Configured displays Read-only Host field

• Note: There are no visual changes here since the field readonly host field that gets displayed here is the same as before in this scenario.

Summary:

Before	After

Networking:

Before	After

Scenario 2. Database Cluster with VPC configured and Public Access set to false displays Private Read-only Host field
Summary:

Before	After

Networking:

Before	After

Scenario 3. Database Cluster with VPC configured and Public Access set to true displays both the Private Read-only Host and Public Read-only Host fields
Summary:

Before	After

Networking:

Before	After

How to test 🧪

Prerequisites

(How to setup test environment)

• Have the databaseVpc feature flag enabled

• Have access to the Databases tab with the ability to create a Database Cluster

• Have VPC and subnets created for a region

• Use mock data or follow the steps below create databases in staging to test each scenario:
  Note 1: This can be tested using the staging environment or with mock data. I'll provide instructions for mock data in the verification steps.
  Note 2: If creating databases, I suggest giving these databases names to indicate the state so they're easy to distinguish (ie. database-with-vpc-public)

• Create a Database with no VPC configuration and, in the Set Number of Nodes section, select 2 or 3 nodes.

• Create a Database assigning a VPC/Subnet with the Enable public access field checkbox checked and, in the Set Number of Nodes section, select 2 or 3 nodes.

• Create a Database assigning a VPC/Subnet with the Enable public access field checkbox unchecked and, in the Set Number of Nodes section, select 2 or 3 nodes.

Reproduction steps

(How to reproduce the issue, if applicable)

• N/A

Verification steps

(How to verify changes)

Note: This change applied to the Read-only Host field and it now mirrors the same behavior for the Host field based on the scenarios below.

Note: You can use mock data to test the scenarios below. For mock data, you'll need to modify the database instance response to response to reflect each Database VPC configuration scenario. If you created the database clusters in staging, you can skip the mock data configuration steps.

Scenario 1. Database Cluster with No VPC Configured displays Read-only Host field

• For mock data, no changes are needed as the private_network property returned from the database instances request is null by default in the database.ts file on line 244 to:
• Access the details for this database cluster and view the Summary tab.
• Verify that, in the Connection Details table, the Read-only Host field is displayed below the Host field (See Before/After screenshots above)
• Access the Networking tab and, in the Manage Networking section connection details table.
• Verify that the Read-only Host field is displayed below the Host field. This should still be the same as the previous display behavior.

Scenario 2. Database Cluster with VPC configured and Public Access set to false displays Private Read-only Host field

• Modify the mock data for a database instance by updating the private_network property in the database.ts file on line 244 to:

private_network: {
  vpc_id: 1,
  subnet_id: 1,
  public_access: false,
},

• Access the details for this database cluster and view the Summary tab.
• Verify that, in the Connection Details table, the Private Read-only Host field is displayed below the Private Host field (See Before/After screenshots above)
• Access the Networking tab and, in the Manage Networking section connection details table.
• Verify that the Private Read-only Host field is displayed below the Private Host field.

Scenario 3. Database Cluster with VPC configured and Public Access set to true displays both the Private Read-only Host and Public Read-only Host fields

• Modify the mock data for a database instance by updating the private_network property in the database.ts file on line 244 to:

private_network: {
  vpc_id: 1,
  subnet_id: 1,
  public_access: true,
},

• Access the details for this database cluster and view the Summary tab.
• Verify that, in the Connection Details table, both the Private Read-only Host and Public Read-only Host fields are displayed below the Public Host field in that order (See Before/After screenshots above)
• Verify that, for the Public Read-only Host field, the hostname value starts with public- instead of private- which is shown in the Private Read-only Host field hostname value.
• Access the Networking tab and, in the Manage Networking section connection details table.
• Verify that both the Private Read-only Host and Public Read-only Host fields are displayed below the Public Host field in that order.

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 tests and CI checks are passing
• TypeScript compilation succeeded without errors
• Code passes all linting rules

[smans-akamai]

The main changes for this pull request are here. I made the same type of change that I made to the Host field in my previous PR so that it renders the different variations of the field based on the VPC configuration.
(ie. Read-only Host, Private Read-only Host, and Public Read-only Host)

[smans-akamai]

According to the documentation, the backend doesn't always provide these hostnames. There's existing logic in the UI to add a placeholder for these fields as well, so I've updated the interface here to reflect that.

For standby, it seems to be excluded from the hosts object for single node clusters. I'm not sure what scenario excludes primary but I assume that's handled the same way. Going to check with the backend to make sure.

[smans-akamai]

Checked with the backend and the Hosts object can be null. Changing this to update the hosts type in the DatabaseInstance interface instead

[linode-gh-bot]

Cloud Manager UI test results

🔺 3 failing tests on test run #5 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
3 Failing	833 Passing	13 Skipped	42m 58s

Details

Failing Tests
	Spec	Test
❌	clone-linode.spec.ts	Cloud Manager Cypress Tests→clone linode » can clone a Linode from Linode details page
❌	create-firewall.spec.ts	Cloud Manager Cypress Tests→create firewall » "before all" hook for "creates a firewall without a linode"
❌	create-firewall.spec.ts	Cloud Manager Cypress Tests→restricted user cannot create firewall » "before each" hook for "confirms the create button is disabled on the Firewall Landing page"

Troubleshooting

Use this command to re-run the failing tests:

pnpm cy:run -s "cypress/e2e/core/linodes/clone-linode.spec.ts,cypress/e2e/core/firewalls/create-firewall.spec.ts"