Implements filter-based architecture for usage enforcement.
One filter is initially included: MaxLeaseDurationFilter allows
operators to define the maximum duration of a lease in seconds. All
filters must be enabled and configured in the [enforcement] group of
blazar.conf.
When ending a lease, the allocations currently associated with the
reservations of the lease are sent to the enforcement layer for
processing. This works fine when deleting a lease, but when a lease
naturally ends, that is, when the current time is greater than the
lease's recorded end time, the allocation lookup returns 0 results
because we have a filter on the time of the lease/reservation by
default, which starts from datetime.now. This is really not what we want
to do when explicitly filtering on a lease/reservation, so this updates
the generic query function to not apply this filtering in this case.
It turns out, it was possible for usage enforcement's on_end hook to run
multiple times if the first reservation teardown failed. In this
circumstance, the end_lease event would be IN_PROGRESS but the
reservations would be in an error state. The code only checks if any
reservation is DELETED before trying to run on_end again.
To fix this, only try to run on_end if we detected that there was an
UNDONE end_lease event; that's the only time in which we'll actually be
responsible for running this logic.
This also updates the delete logic to be a bit more consistent with the
internal way we track states. It is not enough to check dates, because
it could be that Blazar never got around to actually starting the
leases; we should be checking events. This also makes the logic a bit
easier to understand.
Change-Id: Ic106bee4fc3f5c401c4f8d8ecb1c4e735560bcc2
Co-Authored-By: Jason Anderson <jasonanderson@uchicago.edu>
Co-Authored-By: Pierre Riteau <pierre@stackhpc.com>
Implements: blueprint flexible-reservation-usage-enforcement
d3f77fd0c5