Variable Presets: The Great Idea With a Bad Name

One of my favorite things about the way we approach how we do things at Tuono is our dialog with customers and learning how we can help solve their problems. Sometimes, these conversations bring up new feature ideas for us—that’s where presets come from.

Everyone knows some problems bring more challenges than others and presets turned out to be one of them.  Let’s reflect on some commonly held wisdom in my profession:

Hard problems in computer science
personal note: I rolled my eyes every time a former manager made this joke, hopefully he’s reading

Well, the good news is we don’t have a cache for presets and we’re not off by 1 ever. But we DO have a pretty bad name for a pretty cool feature. A preset is a way to set a series of variables as a group to meet a particular configuration need, kind of like a radio preset. It’s really too bad someone beat us to “radio buttons”. So let’s skip the bad name, and talk about what they are. And maybe someone reading this will have a better name: find me on LinkedIn and send me your best ideas.

So let’s say I’ve got a VM in my production network, it’s a pretty big VM, so I define it something like this:

compute:
  vm:
    my-great-vm-prod:
      cores: 16
      memory: 64 GB 

Well that’s cool, but that’s a pretty expensive VM. Fine for production, but maybe I don’t want development instances costing me that much.

compute:
  vm:
    my-great-vm-dev:
      cores: 4
      memory: 32 GB

And it may be that when I’m sending this through QA, I want it resource constrained so exhaustion scenarios can be more readily be tested:

compute:
  vm:
    my-great-vm-qa:
      cores: 2
      memory: 4 GB 

Adding variables

This is where our variables come in. I can describe all three environments with one blueprint and then just set my variables:

variables:
  deploy_type:
    type: string
  vm_cores:
    type: integer
  vm_memory_gb:
    type: integer

compute:
  vm:
    my-great-vm-(( deploy_type )):
      cores: (( vm_cores ))
      memory: (( vm_memory_gb )) GB 

And now presets

But we KNOW how much we want for each of these, so why do I have to set two variables? Why not have one that just controls the others? And that’s where presets come in: define your variables that are controlled by a preset, then define your preset to indicate their value for each preset.

variables:
  vm_cores:
    type: integer
    preset: True
  vm_memory_gb:
    type: integer
    preset: True

presets:
  deploy_type:
    dev:
      vm_cores: 4
      vm_memory_gb: 32
    qa:
      vm_cores: 2
      vm_memory_gb: 4
    prod:
      vm_cores: 8
      vm_memory_gb: 64

compute:
  vm:
    my-great-vm—(( deploy_type )):
      cores: (( vm_cores ))
      memory: (( vm_memory_gb )) GB 

You’ll note, too, I can use my preset as a variable as well, so deploy_type set automatically without having to use an extra variable.

This is a simple example, but we can see how our blueprint gives us complete control over our object parameters, and by using presets, we can create standardized classes of objects controlled by setting a single value.

Now, if only we had a better name for them!

Deploy your first environment