uroflavin
commented
3 years ago The scaling is controlled by the server type. This is mapped in the label 'server_type', e.g. "server_type: ccx32".
Ideas for possible implementation variants Variant: appointment location You could control the overwriting by specifying the server type in the location in the appointment. This is probably the fastest way to implement it, but it prevents future use cases where you might want to control some more things via the appointment entry, e.g. the datacenter or token etc....
Variant: Key-Value in appointment description Or you could do this via the description of the appointment. Per line one key - value pair is allowed, which is then evaluated. This implementation is more complex, because the whole message description must be parsed and evaluated. However this processing offers the largest future use, because further things, e.g. Datacenter, can be easily controlled.
Currently only one configuration per combination of Hetzner project, label: token and calendar is possible.
Temporary scaling and using some other server-type is not possible in this automated way. If you want to scale temporarily, you have to keep a separate token for each asset (firewall, ssh-key, floatingip,...).
It needs to be possible to set variable scaling for each appointment. This scaling then overwrites the preset scaling from the label.
This time limited scaling should not lead to the creation of new snapshots. Upscaled snapshots cannot be downscaled AFAIK, If one wants to persist, this must be done explicitly and manually
A typical use case is e.g. a videoconference server that has to temporarily host 100 participants for a meeting instead of the usual 10 and therefore needs more CPU and/or RAM.
Disadvantages
A disadvantage of the whole requirement is that it will significantly increase the overall complexity.
The consideration must already be made when evaluating the calendar and generating the time slices. The time slices must also take the machine type into account. Currently, they only take into account the state: ON or OFF.
In addition, the overlap areas between the appointments with different machine configuration must take into account that a server must be shut down - create snapshot if necessary - and restarted with changed machine type and this process costs additional time.
I think that temporary scaling must not be allowed for overlapping appointments. The only chance to map this cleanly is if there is always at least one time slice between the machine configurations/appointments as a buffer.
TODO