Add the ability to flag Shell Attributes for Abstract from Web Portal

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.

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.

screen-shot-2018-12-10-at-151403.png

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.

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