This is an IBM Automation portal for Cloud Management and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
firstname.lastname@example.org - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
My opinion is that we should be consistent in all screens we present and have the same format no matter what for understandability and ease-of-use. So I'd rather vote for always display the same columns, and if something cannot be filled-in mark it as "N/A" in the Action Center.
However, having an option to define different policies depending on the fact that actions would be disruptive or not would be an amazing addition! :)
I don't want to let the debate over how we display container action disruptiveness get in the way of maybe the more straightforward implementation of this ER for the traditional on-prem virtualization actions.
Any comments on the first three action types I mentioned? Do those sound reasonable?
VM Storage Moves
VM Resize Up (if hot-add is enabled)
There is a challenge here for the definition of disruptive and non-disruptive that cannot be answered by the same bar as virtualization definition.
In containerization, every action will eventually delete the original running workload, whether it is a resize or pod move. In pod moves we have a mechanism that validates that the copy has met readiness and liveness before the original is deleted, or the action failed. This is actually a benefit and in this case a valid failure.
So if we go with the legacy definition of disruptive vs non-disruptive, then every container action is disruptive. But people working with containerized services would not define it that way.
Instead I am working on informing a user about actions that we know will fail because of valid known reasons, such as a resize on an operator controlled workload, or a pod that is a statefuiset, or the OCP kubeturbo is missing a required parameter to move pods.
For this feature an action will either be executable or not, and if not executable tell the user why it is blocked. Some things can be fixed by the user, like creating an ORM for operator controlled workload, but the user will have more information in the action details.
If an action still fails, inform the user with more details (such as container image pull error, which would require the user to fix access to the repo, or fix the deployment container image spec).
But I do not have disruptive vs non-disruptive actions in k8s. Every action is either executable or will fail gracefully, and I want to improve the user understand that.
this is a great idea!