Headline:
Adjust the way Morpheus applies Custom Plans so the CPU, cores per socket, and Memory stay at the current configured value for a VM instead of adjusting back to 1
Description:
Currently, when you adjust from one Custom Plan to another Custom Plan, Morpheus reverts the total CPU count and Memory back to 1, instead of keeping things default to what the current Instance has. This has proven problematic as we use custom plan options as a way to determine a DR tier level as that reconfigure kicks off workflow automation tasks we can use for various backend adjustments.
Unfortunately, we’ve experiences several times where end users adjust the Custom Plan on an instance from one selection to another (say Standard to Replicated) for a more critical role production system, and this reset the CPU and Memory to 1 unnoticed by the end user.
Example/Use case(s):
User has a system in vCenter with 8 vCPU, 32GB RAM, and 200 HD that’s currently using a Custom Plan called “Standard Plan - No replication”
User reconfigures the instance and switches to a “Replicated Plan”, values for CPU and cores per socket stay as they were currently set, same with RAM (so system still has 8 vCPU, 32GB by default going into the new plan)
User hits “okay”, the plan is adjusted and reconfigure workflow automation tasks kick off, instance remains at the 8 vCPU, 32GB RAM, 200HD and no reboot within vCenter occurs.
I think the problem you are always going to run into with this route, is the fact that the primary purpose of the plans is to set (net new provision) and change (reconfigure) resources. There has to be a defined value supplied.
I would be curious if using the price phase solves what you’re trying to do currently with changing plans.
To your first point, understood that the purpose is to change resources. Other users of the product may not have a use case like ours where we might change from one custom plan to another custom plan. The question is, when changing to a custom plan, what should the custom fields be pre-populated with? It would seem to make sense to populate those fields (when reconfiguring) with the current instance specs rather than an arbitrary default setting for the plan.
For example, maybe if changing from a “t-shirt size” of 8gb ram, 2cpu, 100gb storage - to a “custom” plan - the existing 8gb, 2cpu, and 100gb storage would populate into those fields and the numbers could then be changed by the user if they choose to. (Maybe they want to add 2 more cpu but want to leave ram and storage alone). This prevents the user from having to remember and re-set the ram and storage settings.
As for the price phase, I don’t see how this would accomplish what we’re looking for. My understanding is just that it overrides plan pricing. How would we use this to allow a user to choose a different replication tier at a later time after provisioning?