Persistant availabilities

[AuHau]

Currently, when a new availability is created, is filled up with Slots and then later on these Slots finishes, the availability is not "returned". While this might be useful for some use cases, I would argue that for simple "setup and forget" use cases it is not really convenient as it requires for the host's operators keep in mind when the Slots finishes in order to come back and "refill" the Availabilities.

I would therefore propose adding a "persistent" flag to the availabilities, which would behave in a way that when the slot finishes, the slot's capacity is returned to its original availability which could be automatically offered again.

This would require few things:

• add REST API flag to the Availability JSON structure and keep track of it internally
• add REST API capability to "inactivate" the Availability, in order not to offer it anymore (even with the returned capacity), for the cases when host wants to gracefully terminate its offerings
• wire "refresh signal" for the Sales components (mainly the currently developed Slot Queue) to be noticed that there was a capacity returned to availability and that the Sales process should potentially kick in again

[AuHau]

I have been scoping out the implementation for this, and I believe it would make the most sense to add the property until to the Availability concept. It would function as follows when a sale is completed:

• If no until is specified, the capacity is returned to the availability indefinitely or until until is set.
• If until is specified and is in the future, then the capacity is returned.
• If until is specified and is in the past, then the capacity is not returned and will eventually be depleted.

One concern I have is that users might be a bit confused, as they may expect that "all sales will be finished when until expires." What do you think? We could even expand this modification to ensure that there are no ongoing sales linked to the Availability when until expires.

[markspanbroek]

I really like the until property. Regarding the semantics; I would indeed ensure that all sales are finished before the until timestamp. That should make it easy for node owners to reason about.

[AuHau]

Sounds good to me!

[emizzle]

Sounds great, and I agree with @markspanbroek that on, what I assume is a REST api call to update an Availability, updating the until of an Availability would not succeed unless all active sales are completed before that time.

[emizzle]

Thinking about this again, I feel like the inactive flag and the until flag should be two flags that control the same behaviour (slot queue + capacity recycling), which should be differentiated from deleting an Availability (something we haven't really discussed before). A node operator should be able to deactivate an Availability with active sales, but should not be able to delete it.

inactive/until behaviour

If the inactive flag is true OR until is in the past, then no new slots should be picked up, and capacity would not be returned. If the inactive flag is false OR until is in the future, then new slots should be picked up (assuming the new slot contract completion datetime does not surpass the until datetime) and capacity returned.

Deleting an availability

Deleting an availability is only possible if there are no active sales using that availability. Deleting an availability would also free up any reserved capacity.

Also, my preference would be to name the flag enabled instead of inactive.

[emizzle]

Adding notes here from our discussion:

An inactive flag is valuable in an instance where for example and a node operator is experiencing failing hardware and wants to inactivate their Availabilities immediately so they have time to replace the hardware and no new requests are picked up during that time. In that instance until would not be able to be set to now-1 because the end of the active sale would prevent that.