These forums are a place for learning, helping and sharing experiences with others about any of our products. Feel free to ask a question and get answers from our community and our most advanced users.
Note that these are public forums - anyone can view the discussions here.
Announcements | |
CloudShell | TestShell |
Developers | BI (Business Inteligence) |
This is where you can suggest your ideas to help and improve the product for everyone.
Please make sure to read the following article before posting a new idea, to get more information about the required information and ideas lifecycle.
Feel free to vote and comment on other ideas to promote them.
Thanks for everyone who suggested the ideas and voted for them.
Find, download and share integrations that can extend and enhance the CloudShell experience.
Integrations have several levels:
Certified - Officially tested and supported by Quali.
Preview - Provides a sneak peek to what the Quali team is developing. Officially supported by Quali. Feel free to experiment and comment, but please take into consideration that it is not yet tested and released.
Community - Integrations shared by community users. Feel free to look into what other users have contributed, please take into consideration that these integrations are not tested by Quali.
To learn more about creating Shells and integrating with CloudShell, use the following links:
CloudShell's Dev Guide | Configuration Management |
Getting started with Shells | Extending CloudShell with Cloud Providers |
Getting started with Orchestration | API Guide |
To share your integration, follow the instructions in this guide.
Yaniv Kalsky suggested an idea (#4175) · Dec 05, 2018 at 07:26 PM · user permissionsreservationschedulingadministration
While you can limit a user to a maximum of concurrent reservations and can prevent using recurrence, there is no way to limit the maximum future reservations, so some users are abusing it to create multiple consecutive reservations.
We need a way to prevent this as well.
Ariel Benary commented · Dec 18, 2018 at 03:12 PM
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?
I don't think you'll want to use the same limitation for both concurrent and future reservations.
I might want to limit a user to 5 future reservations while allowing them to have only 3 concurrent ones.
Dan Klingler commented · Dec 18, 2018 at 09:16 PM
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.
Ariel Benary commented · Jan 06, 2019 at 09:03 AM
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
Muli Wienrib commented · Jul 29, 2019 at 10:18 AM
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
Alona Getzler commented · Apr 28, 2020 at 08:31 PM
I'm happy to update this feature is now available in CloudShell 2020.1.
Alona Getzler commented · Apr 28, 2020 at 08:31 PM
I'm happy to update this feature is now available in CloudShell 2020.1.
Extend your CloudShell capabilities by creating your own Shells. Share your knowledge with the world and be part of our growing community
Help us make things better. Share your great idea or vote for other people's.