search

vatesfr / xen-orchestra

The global orchestration solution to manage and backup XCP-ng and XenServer.
https://xen-orchestra.com
Other
741 stars 257 forks source link

Self service feature improvements #4577

Open abaughGHW opened 4 years ago

abaughGHW commented 4 years ago

Context

Expected behavior

  1. Allow Admin to be able to configure default options under self service i.e. have share this VM always enabled, always set VM tag, lock vCPU+RAM+DISK size to template defaults, auto select Install settings to use ISO/DVD or PXE, etc where self service user can't change these options
  2. Under self service make it configurable to set VM memory to Dynamic memory min instead of max(or both since the max field is probably required) so the VMs aren't configured to use dynamic memory control so Admins can choose if they prefer Static or Dynamic memory
  3. Under self service make it possible to use variables similar to "Multiple VMs: Name pattern" to set disk names and descriptions--would work well with allowing Admins to configure default options for self service portal where VM disk name can by {vmname}% instead of randomly generated disk names
  4. Ability to disable/enable message about using a large amount of resources in self service and optionally also allow the Admin to change the trigger point for the message. Should apply to any new future messages or warning to self service users as well.

Current behavior

  1. Self service users can change all values when creating VMs in self service portal
  2. When self service users choose a template and set the RAM higher than the template default. It sets "Dynamic memory min" to the template default and the user specified amount to "Dynamic memory max". Once XCP-ng tools is installed the VM switches to DMC and automatically adjusts memory allocation based on resource availability and demand. --Note that the "Dynamic memory min" value is not shown in self service but is visible after the VM is created.
  3. When creating a new VM under self service the default disk name is "Name of Template"_random characters and the description is a static value passed by XO/XOA
  4. When self service users click create for VMs with resources over 2x the template default they are prompted that they are about to use a lot of resources (example-a template that specifies 1 vCPU will trigger the message if the self service user chooses 3 vCPUs)
olivierlambert commented 4 years ago

Hi!

Thank your for your feedback. To be able to understand more your request, can we know more about your usage context for this feature?

abaughGHW commented 4 years ago

Usage Context

1. Instead of requesting only the fields that affect my use case I requested the general idea of making the self-service portal more configurable as the other fields can benefit use cases that I cannot think of and it would make sense to do it for all fields instead of just a few if you guys see the benefit in it as well. Ideally as the XO/XOA Admin I can set a pre-defined selection for each field or leave them blank for the XO/XOA defaults and from there I can specify if the self-service user can change each field or not. So (1) by default I can set the self-service portal to have “Share this VM” checked and also specify that the self-service user can or cannot change this selection or (2) I can set the self-service portal to have “Share this VM” unchecked and specify if the self-service user can or cannot change the selection. It’s about having more choices to cater self-service to the different types of users and use cases. My specific request is mainly with the “Share this VM” option.

If you have a self-service portal for a user group called “Development" with user Dev1, Dev2 and Dev3 who belong to the same organization and collectively manage their resources. Dev1 creates a VM and does NOT select the check box for share this VM so XO/XOA marks Dev1 as the VM Admin. Dev1 goes on vacation to Mars and the VM needs to be rebooted but Dev2 and Dev3 cannot reboot it since they are not Admin’s for that VM.

2. In my environment I do not use dynamic memory—or rather I try not to as I have had issues with it since my XenServer days and occasionally now with XCP-ng as well when migrating VMs. Since I provide others access to create VMs through XO/XOA self-service when they create new VMs with different specifications from the template and install the guest tools it sets the VM to use dynamic memory. It is too difficult a task for others to ensure their VMs have matching dynamic memory min/max and it’s an impossible task for me to go behind everyone checking their VMs continually to ensure all VMs have matching dynamic memory min/max. Having a way to configure and enforce this setting under self-service at VM creation would fix this issue for me and allow Admins to decide what method is best for their environment.

3. This is another general improvement that I think goes well with request # "1" above making the self-service portal more configurable. Currently when creating a VM under self-service it creates the disk name as “TEMPLATENAME_randomstring”. It serves no specific beneficial purpose or use case other than pre-selecting a disk name. If improvement request # "1" is implemented then the XO/XOA Admin could use this feature along with # "1" to define a different naming convention for disk names such as “VMNANE_diskposition” where VMNAME is a variable of whatever the user types into the VM name field and diskposition is the mount position of the disk. This also opens up a lot more possible use cases if all text input fields where made to support variables such as the VM and Disk description fields so they can be configured to convey useful information as well as defined by the XO/XOA Admin.

4. The self-service message about using a large amount of resources currently does not seem logical since it’s based on template default values. Under self-service the user is given a certain amount of resources within the environment to consume and it is their choice how much of it they can consume in one VM. So on a template that has 1 vCPU by default assigning 3 additional vCPUs out of a hypothetical 300 vCPU still triggers the message. Originally I requested being able to enable or disable this message as an option in self-service but after giving it more thought two better implementations came to mind: (1) present this message to XO/XOA Admin if they have multiple or even just one self-service portal where the total allocated resources is more than the pool can support using some definable over subscription ratio or even a pre-selected one based on your supported user base and/or (2) present this message to self-service user if they have chosen VM resources that cannot be physically supported by the smallest host of the cluster i.e. smallest host has 8 total CPUs but they created a VM with 12 vCPUs, etc. The idea is to warn them that they may encounter issues.