GCE Provider - Is there any way to set multi-zone provider?

[Hdom]

https://github.com/cloudbase/garm-provider-gcp
When you configure the GCP provider it makes you select a zone, is there any way to select "auto" like you do in the UI and have it automatically select a zone?
I would like to distribute the load across multiple zones without having to create multiple providers and pools.

[gabriel-samfira]

In theory, it should be possible. If the SDK can handle it without us having to remember in which region the VM was created, it should be an easy addition. If not, we might have to update the provider interface and allow providers to set some opaque data on the instance similar to extra_specs.

I have a few days of free time coming up. I might be able to squeeze this in.

[Hdom]

Hey @gabriel-samfira have you had a chance to look into this? we had an incident today where all of our VMs started failing to create and it ended up being an issue related to the zone that we had picked, us-east4-c. Switching to us-east4-a(or b) fixed the issue. We will be working on a custom "zone balancing" feature that will pick at random from a list of zones if provided and retry on a different zone if it fails.

[gabriel-samfira]

I have not. The scale sets thing took longer than I thought it would (because it's never as easy as "just one weekend"). If you do want to implement this, and you need to keep track of which region the VM spawned in, keep in mind that you need to record the parameters you used to create a VM, somewhere. Otherwise, after you create the VM, the provider won't be able to find it again.

[Hdom]

Thoughts on using a hashing function based on the runner name to pick a zone from the list?

[gabriel-samfira]

If the provider is to do the hashing you mention and picking the region is transparent to GARM, then it might work. Just make sure it's deterministic.

There is one other possibility. There is no reason why you couldn't make the GCE provider somewhat stateful. Right now, all providers are stateless, but there is a long term plan to make the providers capable of being deployed as a daemon we can call into via REST or gRPC. So in the future, there is no reason why the providers themselves won't be able to hold some state. Like where a certain runner was created, what resources it needed to associate to the runner (disks, nics, security groups, etc). You could use a simple sqlite database for that. Runner names are unique, so you should have no collisions.

So, dealer's choice I guess.