Instance custom SSH key select

[benjaminleonard]

Starting to block out the UI for this (hopefully with some support from @charliepark on this and omicron).

The text area is within the checkbox which is worth looking into incase of accessibility ramifications. But it does make the alignment easier.

This PR adds the CheckboxGroup component, modelled off the RadioGroup.

---

Here's the types I am proposing. Names might not be quite right. We might also accept either InstancePublicKeys[] or an alternative value that includes all of a user's SSH keys – or decide that it can be added to the console and/or CLI but a user can grab those SSH keys themselves (as we are doing here) if they're creating an instance with the API.

export type InstancePublicKeys = 
  { key: NameOrId; type: 'user_key'} |
  { key: string; type: 'string' }

/**
 * Create-time parameters for an `Instance`
 */
export type InstanceCreate = {
  description: string
  /** The disks to be created or attached for this instance. */
  disks?: InstanceDiskAttachment[]
  /** The external IP addresses provided to this instance.

By default, all instances have outbound connectivity, but no inbound connectivity. These external addresses can be used to provide a fixed, known IP address for making inbound connections to the instance. */
  externalIps?: ExternalIpCreate[]
  hostname: string
  memory: ByteCount
  name: Name
  ncpus: InstanceCpuCount
  publicKeys: InstancePublicKeys[]
  /** The network interfaces to be created for this instance. */
  networkInterfaces?: InstanceNetworkInterfaceAttachment
  /** Should this instance be started upon creation; true by default. */
  start?: boolean
  /** User data for instance initialization systems (such as cloud-init). Must be a Base64-encoded string, as specified in RFC 4648 § 4 (+ and / characters with padding). Maximum 32 KiB unencoded data. */
  userData?: string
}

---

• Add SSH key validation (likely just required)
• Accessibility checks
• Omicron API work
• Documentation updates (especially if the default behaviour is no longer injecting all of a users SSH keys)

---

Related issues:
#1818
oxidecomputer/omicron#3056

[vercel]

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

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	Jan 31, 2024 6:37pm

[david-crespo]

Not sold on taking up all that space to allow pasting in a one-off key. Is this aimed at preventing someone from having to leave the flow because they didn’t know to add a key beforehand? What about a button that pops up the SSH key add modal? Maybe a little confusing because unlike the disk modals, which are building up the request body but not hitting the API, that one would actually add a key.

[benjaminleonard]

The text input only appears if the "New SSH Key" checkbox is checked. So 99% of the time it's not visible. I think some kind of button modal flow would imply the SSH key sticks around outside of the instance.

[david-crespo]

Ok, that makes sense. On the API shape, I think we can avoid having two types of things in the list because there is already a user_data field on the instance create request body, so we could use that for the one-off key, and keep the list of keys only for existing ones with NameOrId.

[david-crespo]

Sorry, I’m mashing buttons on my phone.

[benjaminleonard]

Ok, that makes sense. On the API shape, I think we can avoid having two types of things in the list because there is already a user_data field on the instance create request body, so we could use that for the one-off key, and keep the list of keys only for existing ones with NameOrId.

That would be simpler. Does that mean we can have multiple public_keys in the cloud init config?

[benjaminleonard]

Might also be worthwhile adding the user_data free form or file input field to this PR too.

[david-crespo]

Right, good point. And yes, I think we could have multiple one-off keys in there. It’s free-form.

[zephraph]

Instead of having New SSH Key as some hybrid select/button logic how about we just allow opening the side modal form (like for regular SSH key creation) via a button and give the user the option to save or not save the SSH key.

When you're first going through the flow (we'll have plenty of first time instance creators) it's easy to get here an not have an SSH key. This leads to a major point of friction: if you want to persist the key you either have to leave and repopulate the field (as is currently the case) or remember to persist it later. Both seem unfortunate.

[benjaminleonard]

Instead of having New SSH Key as some hybrid select/button logic how about we just allow opening the side modal form (like for regular SSH key creation) via a button and give the user the option to save or not save the SSH key.

I think that could work – I'll hold off on the UI side until we settle on the omicron implementation in case the shape of that API informs this.

But in theory we pass a list of name or IDs of SSH keys. Instance create then takes an intersection of that and the users keys and adds that to the cloud init config. For the new key, we can just insert that into the user_data field directly.

Do we add the SSH key as soon as the user is done with the modal, or wait until the form is submitted.

If we do it immediately, we'll probably want to avoid the mini table / side modal pattern since that is reserved for items which are added when the form is submitted. If we wait and do it at instance create, we need to think about how we handle an error – is the main form blocked? Do we continue with instance create request anyway?

[benjaminleonard]

SSH keys can be added from within the form with a notice to say they will stick around and are scoped to the user not the instance – I experimented with one-time keys but that'd need some more complex work merging it into user_data.

Can now select/deselect all with a checkbox (all keys are checked by default). And we validate to ensure the number of keys is less than the max per instance – currently 8.

Ideally the new keys are pre-selected I suppose, though it might not be worth the work.

[david-crespo]

It turns out this does work. I had forgotten that we changed all form validation to happen on submit, so this will not validate the number of keys until the user clicks submit. It's not ideal as a UX, but it is consistent with everything else. After that initial validation on submit, I think it validates on change, so that is a nice experience.

2024-01-26-sshkey-checkbox-validation.mp4

[benjaminleonard]

Now that this limit has increased to 100, I think it'll be a relatively uncommon occurrence.

[zephraph]

We'll need a nicer UI for longer lists here eventually I think. Looks good for now though!

[benjaminleonard]

Updated API based based on Omicron 5780ff6d1baaa9199e2a64a6b91665d636bf2e3e.
Ready for review.

[david-crespo]

we got it