Cloud Management and AIOps


This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation 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).

Shape the future of IBM!

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:

Search existing ideas

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 your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

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.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Future consideration
Workspace IBM Turbonomic ARM
Created by Guest
Created on Aug 20, 2022

RELATED IDEAS

Add "Non-Disruptive" column to Action Center for On-Prem and Container actions

Today, in the Action Center for many Cloud scaling actions, we have a column highlighting whether the action is non-disruptive or not. This helps customers adopt Turbo's automation quicker, builds trust, and lowers the barriers to action execution.

The same tactic should be taken for on-prem and container actions. We oftentimes have to explain to customers that certain actions do not require downtime - immediately easing their concerns over the effort required to execute/automate actions. No downtime = easier to execute/automate.

Actions today that come to mind are:

  • VM Moves

  • VM Storage Moves

  • VM Resize Up (if hot-add is enabled)

  • Container Pod Moves

Some of these actions may seem obvious that they would be non-disruptive (like VM Moves), but there is no harm in emphasizing how painless it is to execute certain actions. "If you know it's non-disruptive, then why haven't you taken the action yet? :) "

Other actions, like VM Resize Up w/ Hot-Add are actually not obvious to end-users when looking at our Action Center. How do I know which VMs have hot-add enabled? Will this be non-disruptive or disruptive if I execute the action? Today, you have to navigate away from the Action Center, make a group of VMs and filter based on hot-add, and then view just that group's Action Center. With this new feature, the Action Center would make it obvious that a customer has pending VM Resize actions that are non-disruptive - and would help them prioritize executing those actions.

Lastly, Turbo's ability to move (schedule) container pods non-disruptively is such a new concept to people they are almost always unaware it. It's a huge opportunity to have our UX/UI inform the customer of Turbo's unique value prop.

Idea priority High
  • Guest
    Reply
    |     Sep 13, 2022

    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! :)

  • Admin
    Simon Ravenscroft
    Reply
    |     Sep 13, 2022
    There are some useful quick wins we could do here for the specific on prem actions mentioned. Adding an action center column, expanding the filters might be another so it's easy to filter out only the non disruptive actions, expanding the action details. Extending that further, having the ability to define an automation policy for non-disruptive actions might be another. What are the thoughts on which of these and any other ideas on disruptiveness are the most useful and highest value?
  • Guest
    Reply
    |     Sep 8, 2022

    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 Moves

    • VM Storage Moves

    • VM Resize Up (if hot-add is enabled)

  • Admin
    Eva Tuczai
    Reply
    |     Sep 8, 2022

    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.

  • Guest
    Reply
    |     Aug 22, 2022

    this is a great idea!

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.