Limit a user to a number of planned/future reservations

Hi Yaniv,

If I understand you correctly, you would like the max number of concurrent reservations threshold to be applied on future non-recurring reservations, just like it is applied on immediate reservations?

Can you please provide info on which customers have found this problematic for them?

Hi Yaniv, Ariel,

I'm from Cisco DevNet Sandbox, and this feature is absolutely something we need and would use!

A couple of facts. We only allow users one concurrent reservation. We have disabled recurring reservations. We have several labs where there is a single instance of the lab (limited by HW). These labs often become over-subscribed where they are booked out weeks in advance.

The problem we have is that we have no mechanism in place today to prevent a user from making multiple future reservations with one of these labs. So a user can essentially book solid a particular lab and prevent others from making reservations in a reasonable time frame. We just had one user that made multiple, future reservations for 6 months straight. We had to first become aware of this usage pattern, and then manually rectify it. Messy!

A future reservation limit, as Yaniv has suggested would be very valuable for us. And again, it should be a separate limit from the concurrent reservation limit.

Thanks for the Info Dan.

Adding an option to limit the number of reservations (immediate/future), regardless of the concurrency count, sounds like a good idea. I suggest we see if this proves valuable to additional customers.

For the mean time, this goal can be achieved by applying custom logic in a server extensibility hook.

Regards

Ariel

This should also be rolled into RBAC

Hi,

This suggestion sounds like it could be very useful in preventing reservation abuse, and provide better control in resource management.

This could be solved in 2 ways:

1. Limit number of future reservation a blueprint can be used.

2. Limit number of future reservation a user can create.

Regarding option number 2, have you considered limiting future reservation per user group/type?

Please comment with your thoughts, and let me know which approach is better suited for you.

Cheers