config option to disable spawning / evacuate

[FrostyX]

If we want to (temporarily) disable spawning new resources, we need to edit /etc/resallocserver/pools.yaml and set max: 0 for each pool section. This is too cumbersome as we have 10 pools in Copr.

I would like to propose some boolean option into server.yaml or some main section in pools.yaml that would supersede the max value and temporarily disable spawning new resources.

[praiskup]

I would propose a pool config: evacuate: true

• no new VM is started, till diabled
• VMs that have no ticket are terminated
• VMs that have some ticket are terminated immediately once the assigned ticket is closed resolved

[praiskup]

Or if you want something more fine-grained, e.g. evacuate: <mode>. Mode can be "full", "wait_for_ticket", "dont_allocate", etc.

[FrostyX]

I would propose a pool config: evacuate: true

I like your idea, sounds good, but I have an alternative proposal, you can pick which one you want to be implemented.

Since PR #79, we now have an easy way for terminating all resources by resalloc-maint resource-delete --all and resalloc-maint resource-delete --unused.

Maybe we could add resalloc-maint pause command that would create e.g. /var/lock/resalloc.lock. If such lock is found, the resalloc server will behave like you said:

• no new VM is started, till diabled
• VMs that have some ticket are terminated immediately once the assigned ticket is closed resolved

Then by running resalloc-maint resume the lock file would be deleted and spawning started again. Therefore for example Copr maintenance would look like:

resalloc-maint pause
resalloc-main resource-delete --all
# Whatever maintenance tasks needed to be done
resalloc-maint resume

I like this solution better because I would expect a command for doing this instead of a config option (even though I originally reported the RFE as a config option), but that is just my subjective feeling. But I think it may also have some advantages, such as one could safely run ansible playbooks and replace the configs, and the spawning won't be accidentally resumed.

Lastly, the naming is just a suggestion, it can be pause/resume, disable/enable, stop/start, or even evacuate --true/--false. The lock file could also be whatever, /var/lock/resalloc.lock, /var/lock/resalloc/spawning.lock, ...

What do you think?

[praiskup]

I am fine with the proposal! But technically I don't think we should create
lock files ... just use database for locking.

Also, what you propose is not a per-pool setting — but all or nothing. I think
it is OK, it will work for most of our use-cases (and more fine-grained option
can be added later).

[FrostyX]

But technically I don't think we should create lock files ... just use database for locking.

Sounds good to me

Also, what you propose is not a per-pool setting — but all or nothing.

True, I was only in situations when I needed to pause all pools, so I
haven't considered a more fine-grained solution. But I think it should
be very easy to implement thanks to your suggestion about using a
database instead of lock files. I would implement this as

# models.py
class Pool(Base):
    ...
    paused = Column(Boolean, default=False)

and the resalloc-maint pause command as

for pool in pools:
    pool.paused = True
commit()

Then it would be easy to add cmdline parameters for specifying pool
names and filtering the pools list.

[praiskup]

+1