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.
Kimo Saper suggested an idea (#796) · Oct 21, 2016 at 09:53 PM · cloudshell
Pascal Joly commented · Oct 21, 2016 at 10:38 PM
Mohamed Hamdi commented · Jul 22, 2018 at 08:52 AM
Hello,
Will this feature be released soon?
We need to restrict jobs scheduled to run via CloudShell portal to be executed on specific execution server by domain, i.e., each domain should have specific execution server(s) which can be used to run the scheduled jobs.
Hi, thank you for your comment.
This feature is currently not on our backlog. However, there is another way to achieve what you described - you can define specific execution servers (one ore more) per job. See this article in our online help (item 7 under "Add jobs to an automation suite").
Mohamed Hamdi commented · Jul 24, 2018 at 08:53 AM
Hi @Alona.G,
Thanks for your prompt response.
We've done exactly what you suggested. However, it will be useful to have the ability to assign specific Execution Server(s) to specific domain so that when "Any" is chosen, one of execution servers assigned to the domain of this test suite will run this job.
Kimo Saper commented · Jul 30, 2018 at 08:39 PM
@alona.G your suggestion here is for TestShell, which wouldn't apply for Sandbox Orchestration or for asset Shells.
Hi @ksaper@tsieda.com, for Shells you can define Execution Server Selector as a custom attribute to the shell and assign a specific value per resource.
For orchestration the only option available today is assigning a specific Execution Server (or group of execution servers) to all the orchestration scripts, using the key EnvironmentCommandsESRestrictions (see info here).
Kimo Saper commented · Sep 24, 2018 at 10:44 PM
Still the advantage of being able to assign (or limit) execution servers to a specific domain is that it's a one time set up, just for the execution server. Vs. setting that value to each and every inventory item in that domain. In addition, by assigning it at the server level, you could allow for a pool of execution servers in the the domain.
Being able to assign it on a resource level is also useful, especially if there is some other software that is going to co-locate on the execution server that it might need. Just generally I would find the server level assignment easier to manage over the long run.
Ben Abrams commented · Dec 06, 2018 at 11:30 PM
"If the idea of a domain is a group/set of resources, many times they share a specific network or network zone."
This is our exact usecase. We have Cloudshell Orchestration and shell scripts that need to run on specific execution servers due to network limitations. Happily, these limitations are also tied to Cloudshell domains, and so we would like to create a pool of execution servers for Domain X.
"the advantage of being able to assign (or limit) execution servers to a specific domain is that it's a one time set up, just for the execution server. Vs. setting that value to each and every inventory item in that domain"
I agree whole-heartedly with @ksaper@tsieda.com 's comments above. Having to set and maintain an execution selector attribute on every resource within a domain is challenging.
Hopefully, there is also a method that I'm not aware off for directing orchestration script execution to particular execution servers. Having 2 different solutions for directing script execution is non ideal; again arguing for the solution proposed here.
Shaul Ben Maor commented · Jun 02, 2020 at 06:00 PM
Hi Kimo,
We are planning to allow Test Execution Servers to be associated with Domains in our future versions.
Thanks,
Shaul
Alona Getzler commented · Jun 02, 2020 at 06:02 PM
Hi, I'm happy to update that we are planning to support associating test execution servers with domains in the near future. However, associating execution servers to domains won't be supported for the use case of running resources and sandbox commands .
Kimo Saper commented · Jun 08, 2020 at 05:55 PM
@Alona Getzler - Asking for some additional clarity on this feature.
What exactly gets run by the 'Test Execution Servers'? Is that just TestShell Tests (and is that based on what blueprint a Job Suite is assigned to or from the Advanced/Domain option).
When you say 'running resources and sandbox commands' are not covered - Is that Shells? The majority of what is being handled now are generated by Python venv, created for shells and sandbox orchestration. Is that what is excluded here?
Hi Kimo,
The feature will be supported for all types of test automation framework supported on test execution servers (TestShell, Robot,...). You are correct that for the time being that does not include running commands created using Shells.
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.
Help us make things better. Share your great idea or vote for other people's.
Instruction panel width control request
Ability to 'pop' the vSphere Console for vSphere resources
Input parameters as radio button
Extend Python cloudshell_api to add/delete script to/from environment
Domain admins need the ability to create and connect resources in their own domains
Connectivity search filter at the chassis level
pecify default auto arrange feature for an environment in portal
Single command to save a SnapShot of all VMs in a sandbox
Expose the "Update local tests" button in CloudShell to all users
Multi Line Text Box Option for Entering Input Parameters into a Library Function