Add Transit IPs column to instance NIC table

[charliepark]

This adds a column for Transit IPs to the Instance NIC table …

… and an update to the NIC edit form:

It is worth noting that it is currently the case with the API that transitIps can be added to an existing InstanceNetworkingInterface — https://github.com/oxidecomputer/console/blob/main/app/api/__generated__/Api.ts#L1902-L1918 — but not passed in when creating a new one — https://github.com/oxidecomputer/console/blob/main/app/api/__generated__/Api.ts#L1801-L1813. We might change this in a future PR once we get clarity about the intent of that feature, but I want to keep this PR scoped to the existing API.

Closes #2381

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	Sep 19, 2024 10:41pm

[charliepark]

Current state of this UI:

Not sure what I think about that new tab link icon inlined there. Maybe fine.

[charliepark]

I passed the Vercel preview link to Angela for review, and she said the new column and updated form look good.

[charliepark]

For posterity, here's the current state of the UI:

[david-crespo]

Looks great! Hm, what do you think about collapsing it under an Advanced thing like we do on some other forms? The argument against would be that the main reason anyone would want to use this form ever is to make a NIC with some transit IPs. The other argument against is that it's much less obtrusive than in that screenshot when you haven't actually added any.

[charliepark]

I'm inclined to not tuck it into a collapsible Advanced section. The form is such a simple one (name, description), I don't think including the Transit IPs section overwhelms the user. I think it makes sense on something like Instance Create because the form has so much going on.

[david-crespo]

I think we might have to do some client-side validation of the IPs to get a decent experience around malformed transit IPs. The alternative would be to catch the server's validation error and turn it into something more usable, but I think client-side validation preventing the whole error in the first place would be both easier and more maintainable.

This is what I get pointing local dev at dogfood:

2024-09-19-bad-transit-ip-validation.mp4

We do have a validateIp function that uses rather elaborate regexes, but I don't think they handle CIDR blocks, so I guess we'll want to add that somehow.

console/app/util/str.ts

Lines 57 to 67 in 1625d02

	const IPV4_REGEX =
	/^(?:(?:[1-9]|1\d|2[0-4])?\d|25[0-5])(?:\.(?:(?:[1-9]|1\d|2[0-4])?\d|25[0-5])){3}$/u
	const IPV6_REGEX =
	/^(?:(?:[\da-f]{1,4}:){7}[\da-f]{1,4}|(?:[\da-f]{1,4}:){1,7}:|(?:[\da-f]{1,4}:){1,6}:[\da-f]{1,4}|(?:[\da-f]{1,4}:){1,5}(?::[\da-f]{1,4}){1,2}|(?:[\da-f]{1,4}:){1,4}(?::[\da-f]{1,4}){1,3}|(?:[\da-f]{1,4}:){1,3}(?::[\da-f]{1,4}){1,4}|(?:[\da-f]{1,4}:){1,2}(?::[\da-f]{1,4}){1,5}|[\da-f]{1,4}:(?::[\da-f]{1,4}){1,6}|:(?:(?::[\da-f]{1,4}){1,7}|:)|fe80:(?::[\da-f]{0,4}){0,4}%[\da-z]+|::(?:f{4}(?::0{1,4})?:)?(?:(?:25[0-5]|(?:2[0-4]|1?\d)?\d)\.){3}(?:25[0-5]|(?:2[0-4]|1?\d)?\d)|(?:[\da-f]{1,4}:){1,4}:(?:(?:25[0-5]|(?:2[0-4]|1?\d)?\d)\.){3}(?:25[0-5]|(?:2[0-4]|1?\d)?\d))$/iu
	export const validateIp = (ip: string) => {
	const isv4 = IPV4_REGEX.test(ip)
	const isv6 = !isv4 && IPV6_REGEX.test(ip)
	return { isv4, isv6, valid: isv4 || isv6 }
	}

We're already using the impressive and robust-seeming ip-num library in the mock server

console/mock-api/msw/util.ts

Line 11 in 1625d02

import { IPv4, IPv6 } from 'ip-num/IPNumber.js'

...but we're not yet using it anywhere in the app code. I wonder if we could replace our IPv4 and IPv6 regexes with calls to this library, as well as using it to validate IP networks.

console/app/forms/ip-pool-range-add.tsx

Lines 57 to 58 in 1625d02

	// TODO: if we were really cool we could check first <= last but it would add
	// 6k gzipped to the bundle with ip-num

[david-crespo]

As discussed in chat, I'm working on some IP network validation utilities. I think we should merge this without validation and add it as a followup.

[david-crespo]

Nice! We will follow up with IP address and network validation.