[Instance create] `user_data` textarea/file input

[david-crespo]

Discussed in chat. This is not fully fleshed out, but it's in the API. user_data is an optional string field on the instance create POST. The easy version is a text area you can paste into. The fancy version would also allow a file upload. This is sort of an advanced feature on instance create, so we would probably want to hide it in a collapsed section.

[iliana]

Possibly worth noting here that:

• the client needs to base64 the user data before making the request
• the limit is 32 KiB (before base64-encoding)

(This should be documented in the OpenAPI definition as well.)

[zephraph]

I think we could use some clearer requirements here.

@iliana a few questions for you

• What's the priority of this? Is it something we need by the first customer demo?
• Is the data here only expected to be valid json? Is there any other restrictions on the shape of the data?

cc @benjaminleonard this'll be something we need to design for.

[iliana]

Mediumish priority probably? I commonly use it when launching AWS instances but just to change my username with a cloud-config I practically have memorized. But it doesn't stop you from launching an instance in the usual case, and most use cases for user data are best served by the API and tools like Terraform.

There are no restrictions to the shape of the data apart from what I mentioned in https://github.com/oxidecomputer/console/issues/800#issuecomment-1100374187; in the usual Linux case, cloud-config is either a YAML document, shell script, MIME multipart document, etc, or can even be a gzipped form of these. For Windows I could imagine seeing powershell scripts. Hence why it'd be good to have either the free-form text field or the file upload (for the gzip case).

[benjaminleonard]

I think we could use some clearer requirements here.

@iliana a few questions for you

• What's the priority of this? Is it something we need by the first customer demo?
• Is the data here only expected to be valid json? Is there any other restrictions on the shape of the data?

cc @benjaminleonard this'll be something we need to design for.

I have an upload component, but it's a bit spicy and probably goes beyond what we need for the end of July. It's a bit heavier to handle multiple files, and progress on larger files (going to be especially important for images I think).

If that gives you nightmares, we can stick with a regular file input field and I'll work out a quick interim style for it.

Also if it's a text file, maybe we can allow drag and drop directly onto the textarea, it uploads and populates the textarea with the contents? Or is that just fantasy?

[david-crespo]

Because it's sent as a base64 string in the JSON POST body, we actually have to read the file contents in the browser no matter what. So it's not really a file upload. Whether we then display the contents in a textarea (editable or not) or just hold onto it and say "we've got your stuff right here, we promise" — it's easy to try out both ways and see how we like it. 32 KiB is on the big side to be pleasant to look at in a textarea, but I imagine 99.9% will be much smaller than that.

Probably a good idea to give the user the option to drop or paste, so: a file drop box with a textarea underneath. You can paste in the textarea, or if you drop a file in the box, it puts the contents in the textarea (overwriting anything that was there, maybe with a confirmation). You could make the textarea the file drop spot too, like you suggest, but that might be harder to explain in copy (and less visually self-explanatory), like "type here, or drop a file on here, you can do whatever"

[iliana]

or if you drop a file in the box, it puts the contents in the textarea (overwriting anything that was there, maybe with a confirmation).

I like this a lot; be careful with binary data. Disabling the textarea and having it read [binary data, 12345 bytes] or whatever would probably work pretty well.

[david-crespo]

At this point I'm unwilling to put this in MVP or MVP+1 since as you say it's mostly an API thing. Once we add the drag and drop file component for other (more pressing) reasons, this feature may become so easy to add that it gets bumped up if we have time.

[morlandi7]

Re priority: chat comment (jordan) someone at rustconf asked about being able to upload or write cloud-init scripts directly in the console. I haven't followed this area closely -- is that feasible?

sean (he/him) omicron/nexus/src/cidata.rs is where we generate the cloud-init filesystem, fwiw

[david-crespo]

We do have the drag and drop file component now, so this would be very easy.

[benjaminleonard]

@askfongjojo @iliana @zephraph @david-crespo

Quick pass at this – we're getting to the point where any additions to the instance create add a little clutter and a bit of friction. I'm proposing that we add an "Advanced" section (open to alternative names) that contains an accordion of lesser used inputs. Perhaps we more networking in here since more often than not a user just leaves it at default, and we include the user data file upload there too.

Including both text area and file upload or some hybrid would be a nice touch, but we already have the file upload which makes easy to add and I'm assuming most people's workflows.

If you're happy with that as an approach I could probably squeeze in a PR ahead of the next releaase.

[askfongjojo]

@benjaminleonard - Your proposal sounds good to me.

[david-crespo]

I like it too.