Adopt larger unit sizes for data fields

[lgfa29]

Overview

The Oxide API receives data fields as bytes, but this creates a bad user experience for Terraform where users are forced to type and manage long numbers that are hard to read and easy to mistype.

Instead of receiving byte values, the provider should follow the Oxide dashboard and operate at the gigabyte resolution, since disks and instance memory sizes are often of this order of magnitude.

It can also automatically adjust values when converting them to byte to ensure they meet specific API constraints, such as disk sizes being required to be a multiple of the disk block size.

Implementation details

The migration path needs to be handled with care to ensure that updating the provider does not trigger a diff and potential destructive actions.

One approach could be to deprecate the existing fields and use a new unit suffixed attribute (like memory_gb), but it should also be possible to keep the existing attribute and infer its unit based on size.

A 10GiB disk would be written as 126080778240 bytes, which is far too big to be interpreted as gigabytes. So if a number is larger than a given threshold (for example, 1048576) it's safe to assume the user intended to specify it as bytes and not gigabytes (petabyte disks and VMs are not currently supported).

When a byte value is detected, the provider should warn the user to update their configuration.

Anything else you would like to add?

No response

[sudomateo]

I believe this is a great opportunity to use provider functions. We could have a function that accepts values such as 10 GiB, 10 GB, and others that can be used to convert the value to bytes needed by the provider. That way we don't change the type for the API but give users a nice experience.

What do you think @lgfa29?

[sudomateo]

I realized I didn't comment on the thread to publish to GitHub. Quoting your reply here.

Oh sorry, for some reason I didn't get a notification about this. I need to figure out how to set that up here in Linear.

I think that's probably OK, although it could be a little cumbersome for such a common operation?

size = provider::oxide::parse_size("10GiB") (or whatever we decide to call the function) does look better than size = 126080778240 but it still seems like a lot of unnecessary keystrokes.

I can investigate this further, but I think deprecating this field to replace it with a new suffixed attribute would be fairly straightforward (famous last words 😬)

[sudomateo]

That syntax is a bit cumbersome but I do kinda like it for its ability to keep the resource schema in line with the API. It's also very Rust like haha.

Seriously though I wish the syntax was shorter because the function really does what we want here and gives users flexibility in how they want to represent things in the configuration. Not that I want to solve for problems that aren't here, but if we switched to a suffixed attribute and then the granularity changes we could put ourselves in a situation where we need to switch back. Maybe that's overthinking and overengineering though.

[lgfa29]

I'm not opposed to the function (and kind of wish Terraform would provide this as a built-in function), but I feel like at that point I would personally just use math (like size = 10 * pow(1024, 3)) instead of trying to remember the right syntax.

Another option could be to no deprecate the existing fields and offer the _gb variant as a kind of "shortcut" for the common case, and then users can use whichever makes more sense for their use case.

[sudomateo]

I agree this should be a builtin Terraform function and adding our own provider function would be more syntax noise compared to using builtin math functions.

I think I'll bring this up to a few of our customers for an external opinion. I would hate to make a change that's not well received by users.

Which implementation are you leaning towards?

1. Change the granularity (e.g., memory to memory_gb).
2. Using a string and parsing (e.g., 1 GiB, 1073741824, 1G, etc.).

[lgfa29]

I'm leaning more towards 1. But I think this is good point:

I think I'll bring this up to a few of our customers for an external opinion. I would hate to make a change that's not well received by users.

Similarly to #517, our current sample size is n = 1 😄