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.
VISIT OUR DIFFERENT FORUMS:
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 (#4168) · Dec 04, 2018 at 06:24 PM · cloudshellblueprintabstract resourceadministrationattributes
Blueprint designers, with admin permissions, should be able to easily add attributes from a Shell to the available attribute selection list.
Currently this would require that the Blueprint designer either go back to the Shell author and request the change or download the shell themselves and make the modification. I don't anticipate that Blue Print designers will have the training and/or skill to do this most of the time.
This becomes an unnecessary bottleneck to the workflow.
Alona Getzler commented · Dec 06, 2018 at 01:35 PM
Hi Kimo, thank you for posting this idea.
As we see it, the shell developer is the user which determines which of the parameters are relevant for abstraction and therefore he is the one that decides it during the shell development or customization. We come with some behavior defined in our standards and these definitions can be customized, see our devguide for more information.
Can you give a real world example in which the blueprint designer is the one who determines which attributes should be exposed for abstracts for a certain shell (which shell? what kind of attributes?). By the way, an admin has the power to associate custom attributes with a shell after it was installed in CloudShell, and he can decide if those attributes are exposed in abstracts or not. See the section "Adding Custom Attributes to a Shell" in this article.
Kimo Saper commented · Dec 10, 2018 at 11:17 PM
Real world example.
The Blueprint designer may be a network expert or SME with in their group - but not a programmer. For the blueprint she needs to build, they want to expose an attribute (like OS Version) needed, but it's not currently available from the shell as an abstract.
At this point, they are going to need someone to open up the shell, add the flag and load it back up.
Now image that the customer org doesn't have many (or any programmers on their staff). Suddenly one of the key features of the product is now walled off, because of the move to Shells (vs. the previous RM based modeling of resources).
Example, the screenshot attached is of the Standard CS_Compute/GenericServer - Basic attributes like the OS attributes (Type, Version, Build) are not exposed as Abstract criteria.
Alona Getzler commented · Dec 25, 2018 at 01:04 PM
Hi Kimo, thank you for the detailed reply. So ideally you would like to have some way in the portal's UI to determine which attributes are exposed in abstract per shell, correct?
We will consider adding this to the backlog. Anyway, it is possible to achieve this today by customizing the shell, see section "Adding or modifying attributes in a shell’s root or sub-model" in this devguide article.
Kimo Saper commented · Jan 03, 2019 at 01:02 AM
I'm aware that the can be achieved via modification of the shell-definition.yaml file. The point I'm trying to make is that adding a new attribute for abstract search that's not currently available requires someone with specific knowledge of Shell design to complete the task. This makes a key feature of the product behind a specific knowledge/training barrier (which is counter-productive IMO). With so many Shells available for download directly from Quali, only a few customer will need to make the investment into Shell design.
Blueprint design is a completely different workflow than Shell design. With that in mind, you have to admit, that in a larger organization, that these function would likely be distributed. Even more so if the core 'Environment-As-A-Service' model is the primary function.
EDIT for clarity
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.
Support for more than 1 in Quantity for connected abstract resources
Domain admins need the ability to create and connect resources in their own domains
Blueprint variables inherited from blueprint objects
'Check Blueprint' as an API command
Single command to save a SnapShot of all VMs in a sandbox
Admin level control to create a scheduling Blackout/Service Period
Auto Show Instructions per Blueprint
abstract resource: enforce a single “any” value on linked attributes
Ability to manage Abstract templates between Domains
Email notification for all users or a group of users when Setting up a future maintenance window