Created attachment 1576727 [details] when an user want to override per VM the value that is set per cluster Description of problem: When setting a cluster-wide "Custom serial number policy" value, this is not visible when editing a single VM, with the risk that the defined value is overridden by mistake. Also, end user can think that the VM do not have a custom serial policy by seeing the field in the VM empty, while it is set at higher cluster level Version-Release number of selected component (if applicable): RHV 4.3 How reproducible: always Steps to Reproduce: 1. set a "Custom serial number policy" at cluster level 2. edit a single VM Actual results: - no value is reported Expected results: - to see, in an unmodifiable way, the value defined at cluster level. This RFE is for: a) showing for each VM the value of the policy for the serial numer that is defined at cluster leve b) allowing an explicit override respect to the cluster value. The behaviour is already in place, but is not explicit for the end user. In attachment 2 [details] UI mockup that show a proposal: a) when there's a cluster-wide policy set for the serial: clusterwide_custom_serial_policy_mgmt.jpg b) when an user want to override per VM the value that is set per cluster override_custom_serial_policy_mgmt.jpg
Created attachment 1576728 [details] when there's a cluster-wide policy set for the serial
I looked at this issue. Currently one can enter a Custom Serial Number at the Cluster level and at the VM Level. It is understandable that if one enters the Custom Serial Number at the Cluster level, it should propagate to all VMs in the cluster. However, the expectation in the description that one should see the value at the VM level in an "unmodifiable way" may be problematic, especially when supporting item b: "when an user want to override per VM the value". I believe the easiest way to implement this is: 1. When the user enters or changes the Cluster's Custom Serial Number, all VM's shall have the same serial number if they do not have Custom serial Numbers, or if their Custom Serial Number matches the old Custom Serial Number. 2. The user can still change individual Custom Serial Numbers of any VM to be different. Otherwise, if we display the VM value in an "unmodifiable way", the user cannot set individual VMs separately without resetting the Cluster Custom Serial Number. This does open up many design issues such as when removing the Cluster level Custom Serial Number, we would also remove all VM Level Custom Serial Numbers that match the Cluster's Custom Serial Number. VM level Custom Serial Numbers that differ would be preserved leaving the user to manually change them unless we add more functionality to automatically clear them at the cluster level. Either way the first step is to resolve the discrepancy between "unmodifiable" on the one hand and "override" on the other.
(In reply to Steven Rosenberg from comment #2) > Otherwise, if we display the VM value in an "unmodifiable way", the user > cannot set individual VMs separately without resetting the Cluster Custom > Serial Number. Hi Steven, in my proposalm this is addressed by selecting the checkbox "override cluster value". Selecting it whene there's a cluster policy, it should ungray the fields, making them editable. > This does open up many design issues such as when removing the Cluster level > Custom Serial Number, we would also remove all VM Level Custom Serial > Numbers that match the Cluster's Custom Serial Number. VM level Custom > Serial Numbers that differ would be preserved leaving the user to manually > change them unless we add more functionality to automatically clear them at > the cluster level. In my idea, when removing the cluster level serial nums, VM level serial nums are preserved because has the "override" flag. This works the other way round. If I have a VM with a custom value and then I do force at cluster level a value: - if the override flag is set, the local VM value is preserved - if the override flag is not set, the value is overridden Does this clarify the situation? If we really want to be accurate, in case of removal of the per cluster serial value, we should also restore the previously set local serial.
(In reply to Andrea Perotti from comment #3) > (In reply to Steven Rosenberg from comment #2) > > Otherwise, if we display the VM value in an "unmodifiable way", the user > > cannot set individual VMs separately without resetting the Cluster Custom > > Serial Number. > > Hi Steven, in my proposalm this is addressed by selecting the checkbox > "override cluster value". > > Selecting it whene there's a cluster policy, it should ungray the fields, > making them editable. > > > This does open up many design issues such as when removing the Cluster level > > Custom Serial Number, we would also remove all VM Level Custom Serial > > Numbers that match the Cluster's Custom Serial Number. VM level Custom > > Serial Numbers that differ would be preserved leaving the user to manually > > change them unless we add more functionality to automatically clear them at > > the cluster level. > > In my idea, when removing the cluster level serial nums, VM level serial nums > are preserved because has the "override" flag. > > This works the other way round. > > If I have a VM with a custom value and then I do force at cluster level a > value: > > - if the override flag is set, the local VM value is preserved > - if the override flag is not set, the value is overridden > > Does this clarify the situation? > > > If we really want to be accurate, in case of removal of the per cluster > serial value, we should also restore the previously set local serial. So as I understand this, the development entails adding a new check box with the title "Override cluster-wide custom serial policy number" as per your attachment that will override the cluster settings per VM for those VMs that will be independent.
(In reply to Steven Rosenberg from comment #4) > So as I understand this, the development entails adding a new check box with > the title "Override cluster-wide custom serial policy number" as per your > attachment that will override the cluster settings per VM for those VMs that > will be independent. Exactly. In addition to that, would be nice if the 'old' values inserted before the application of a cluster-wide custom serial policy would be preserved, so in case of removal of the global policy, that previous value would be restored. thanks
Hi Laura, Maybe you can approve the proposed change for the GUI from attachment 1576728 [details]
I have a few suggestions and questions around some of the fields. What do the host and VM ID radio button selections exactly do? Are they similar to assigning a custom serial number? If they are I would try to make that more evident to the user. I would also clarify the wording of "custom serial policy number" vs "custom serial number policy" vs "custom serial number". Is one wording more preferred or common over the others? I have attached a couple wireframes that feature some updates I would suggest. Let me know what you think.
Created attachment 1611265 [details] Serial number 1
Created attachment 1611266 [details] Serial number 2
(In reply to Laura Wright from comment #8) > Created attachment 1611265 [details] > Serial number 1 Actually, when the "Provide custom serial number policy" is not checked, the "Custom serial number". Host ID and VM ID controls are hidden so it would not look like that. The Host Id check box when checked allows for the Host ID to be used as the "custom serial number policy" whereas when the VM ID check box is checked, the VM ID becomes the custom serial number. So I do not think changing the ordering matters being that it is just a different way of specifying the "custom serial number". The modification called for in this issue is actually just adding the Override check box in order to replace the custom serial number policy (whether entered as a custom serial number, usage of the Host ID or VM ID) from the cluster as opposed to keeping these fields independent for each VM. It does make sense that the policy includes not only the "custom serial number", but also Host ID and VM ID both for inheritance from the cluster as well as within the VM itself. Please advise accordingly.
I'd suggest the following: Basically keep the mockups as they are now, except with an entry at the top which indicates whether or not this is set from the cluster level at all (possibly as a condition to even enable "override cluster-wide"). If it is, display the current value, along with the checkbox. This satisfies showing both the value set at the cluster level in an unmodifiable way, and allowing for overrides.
Okay this makes more sense now. In this case I would suggest keeping the fields as they are but just having the serial number field box appear only when a particular ID type is selected. I would also recommend moving the order of the fields so that the override box is the last selection a user could make in the form. Also I would recommend being consistent with the wording that is used to describe the custom serial number policy.
Ok, so keep as is, plus: Override checkbox at the bottom Wording between cluster and VM properties as similar as possible I suppose that, from my point of view, having the checkbox _above_ the fields which will override it makes more sense, but I'm not a UX expert.
Yup that sounds good to me. My reasoning is that from a flow perspective it makes sense for the user to input the serial number first and then maybe make the decision to override.
(In reply to Laura Wright from comment #12) > Okay this makes more sense now. In this case I would suggest keeping the > fields as they are but just having the serial number field box appear only > when a particular ID type is selected. I would also recommend moving the > order of the fields so that the override box is the last selection a user > could make in the form. Also I would recommend being consistent with the > wording that is used to describe the custom serial number policy. I checked these issues: 1. The Serial Number Text Box is visible for both cluster and VM dialog boxes when the Provide customer serial number policy check box is checked, but they are disabled until the user chooses the Custom serial number checkbox. They are consistent, but changing the existing functionality to hide the text box could be confusing for the user. It is usually better practice not to change the user interface unless one needs to. Please advise if we really want to make that change. 2. Moving the Override check box to the bottom is not an issue and will be done. 3. The wording is consistent between the Cluster and VM dialog boxes, so there is no issue here.
Let's not change the behavior any more than we need to. Hiding the overrides is already what's done on the cluster level (Cluster->Scheduling Policy), so it introduces consistency, but all that we should need here is a text field which shows whether or not a value is set from the cluster level, with an override checkbox below (either in an accordion which expands when checked like the cluster properties, or not to keep consistency with the existing VM dialog -- your choice, though I'd vote for changing it to match the cluster dialog as it's 4.4 and we can change the UX a little). If the box is checked, allow the fields to be editable.
That all sounds fine to me.
Created attachment 1617122 [details] Cluster migration UI for cluster
Created attachment 1617123 [details] Cluster migration UI for vm
The same problem with overriding and viewing cluster default values has been solved for migrate options by using combo box. The combo box contains "Cluster default" as the first item + the list of all other items. If user selects "Cluster default", the cluster default will be used, if selects something else, the cluster value will be overridden. As you can see on the attached screenshot, the "Cluster default" item also contains also the actual cluster value. The custom serial number policy could be changed to use combo box instead of radio buttons (Both on cluster and vm dialogs). It would be consistent with migration fields. Laura, what do you think?
Would there ever be a need for the user to enter a custom serial number or would they just select a predetermined one?
To answer your question, the user may need to enter a custom serial number. This is why the current implementation as well as all of these proposals allow for the user to do that. To clarify in order to synchronize, what Lucia is suggesting is that instead of adding an extra check box as per the original proposal we replace the "Provide Custom Serial Number Policy" checkbox with a combo box as per the Migration Policy example. This is due to Michal Skrivanek's suggestion in the gerrit to avoid adding the new check box all together contrary to this request and to create a "tri-state" mechanism instead. This tri-state proposal is to allow the user to choose from the UI point of view between: 1. Disabling the Custom Serial Number Policy - This means the controls below the combo box are still hidden. 2. Utilizing the Cluster's Custom Serial Number Policy - This means the Cluster's values are displayed in the controls below the combo box. 3. Utilizing the VM's Custom Serial Number Policy (equivalent to Override Cluster Wide Custom Serial Number Policy) - This means the VM's values are displayed in the controls below the combo box. One issue is that only the VM functionality should have the override capability. It does not make sense to have this addition in the Cluster because the whole idea is that one can set a Cluster Wide Serial Number Policy at the cluster level and then set a given VM to override the Cluster's Custom Serial Number Policy in favor of the VM's Custom Serial Number Policy. At the Cluster Level there is nothing to override so it does not seem the cluster level and VM level implementation are completely consistent. The current implementation does really support this anyway in that if the VM's Custom Serial Number Policy is disabled, the Cluster's Custom Serial Number Policy is still sent (used) when the VM is loaded. The main reason for this request is that the user can actually see the Cluster's Custom Serial Number Policy in the dialog and for allowing the user to specify the override, even though we automatically override when the VM Custom Serial Number Policy is disabled anyway. Because disabling at the VM level is overriding, there is really not much added value to this request, because one just needs to disable the VM's Custom Serial Number Policy in order to default to the Cluster's Custom Serial Number Policy anyway. It may be more intuitive just to save the previous VM's settings when the Custom Serial Number is disabled at the VM level so it can be reused when enabled on editing the VM than the current proposals. We have a few design issues at this point with these proposals: 1. The Custom Serial Number Policy dialog box is shared by both the Cluster and VM functionality. Being that it does not make sense for the Cluster to have an override, changing the "Provide Custom Serial Number Policy" checkbox to a combo box would mean just providing only two choices, disabling the Custom Serial Number Policy and Enabling the Cluster-wide Custom Serial Number Policy. The VM's functionality would require all three (tri-state). 2. The combo box does change the look and feel and does "change the behavior" from the user's point of view so this discussion is warranted, at least to quantify what is actually necessary as per the users requirements. 3. Because we do use the Cluster's Custom Serial Number as the default when launching the VM when the VM's Custom Serial Number Policy is disabled anyway, the only added value here is that the user can actually see the Cluster's settings in the UI and possibly preserve the VMs settings in case one wants to recover the Vm's Custom Serial Number Policy in the future, though support for this was originally optional. Still, it may be confusing to the user that when the Custom Serial Number Policy at the VM level is disabled that we are using the Cluster's Custom Serial Number Policy even though they did not specify that specifically via the "Provide Custom Serial Number Policy". Still to change the default mechanism can lead to additional complications we may wish to avoid. I hope this clarifies the issues. Please advise accordingly for moving forward.
I think that if you decide to use combo box for selecting values, it should be used for both, cluster and vm. Cluster combo box would look like this: Label: Custom serial number policy Values: None, Host ID, VM ID, Custom VM combo box would look like this: Label: Custom serial number policy Values: Cluster default (actual cluster value), None, Host ID, VM ID, Custom As for the text input, it could be either text box enabled only when Custom value is selected or it could be type ahead combo box as used for selecting custom CPU (VM dialog, System tab, Advanced parameters).
(In reply to Lucia Jelinkova from comment #23) > I think that if you decide to use combo box for selecting values, it should > be used for both, cluster and vm. > > Cluster combo box would look like this: > Label: Custom serial number policy > Values: None, Host ID, VM ID, Custom > > VM combo box would look like this: > Label: Custom serial number policy > Values: Cluster default (actual cluster value), None, Host ID, VM ID, Custom > > As for the text input, it could be either text box enabled only when Custom > value is selected or it could be type ahead combo box as used for selecting > custom CPU (VM dialog, System tab, Advanced parameters). For discussion, one needs to enter in the Custom Serial Number with a Text Box, so just replacing the check box only with say a combo box makes more sense. But as per my description, one can use say the combo box for both, but the cluster would not have the third choice for override from what I see.
Created attachment 1618293 [details] Custom serial number- Cluster and VM Wireframes
I just added some update wireframes based off of the feedback you guys left. Let me know what you think.
These look great. +1 from me
(In reply to Laura Wright from comment #26) > I just added some update wireframes based off of the feedback you guys left. > Let me know what you think. Thank you for the wireframe for the Cluster Dialog when None is chosen. Please provide the following: 1. Wireframe for what the Cluster Dialog Box will look like when the user chooses "Custom" in the Combo Box. 2. Wireframes for what the VM Dialog Box's Combo Box will look like. I assume we will still need the Text Box in order to enter the Custom Serial Number for both Cluster and VM and for the VM we will need an additional Override choice.
The wireframes featuring "custom" selected are included in the same PDF if you scroll through the rest of it.
(In reply to Laura Wright from comment #29) > The wireframes featuring "custom" selected are included in the same PDF if > you scroll through the rest of it. OK, I was hoping you could provide wire frames for the other combinations with the combo box specifically. Your previous examples were with the check box, not the combo box. Anyway, the migration policy example also has a text box for the custom choice so I assume it would work the same way. The combo box is much wider in the last wire frame than the migration policy example which you can see in Lucia's screen shot and the text box when custom is chosen appears to the right. I assume that we would still keep the Text Box for the Custom Serial Number under the Combo Box. I assume for the VM dialog Box that you would want the Override choice to be last on the list, although I would suggest it would be more intuitive to be added after the None, but that it your decision. One word of caution is we are changing the look and feel of the UI and Combo Boxes hide the details until chosen, which some users may find confusing, but has the advantage of reducing the real estate.
(In reply to Laura Wright from comment #29) > The wireframes featuring "custom" selected are included in the same PDF if > you scroll through the rest of it. OK I see you put multiple wire frames in the same pdf which does address my comments. Thank you.
Few comments to the wireframes: Cluster - the label is too long - could it be just Serial number policy? - I checked the code and if no serial number policy is selected, default values from configuration are used. We should show that in the UI in a similar way as for the migrate fields So the combo items might be: - System default (serial number policy read from the configuration) - Host ID - Vm ID - Custom If the System default is selected and it is Custom policy, the serial number should be shown in the text box but could not be modified VM - no need for the checkbox since selecting any other option than Cluster default means you want to override - no need for None option since selecting None is equivalent to Cluster default
(In reply to Lucia Jelinkova from comment #32) > Few comments to the wireframes: > > Cluster > - the label is too long - could it be just Serial number policy? > - I checked the code and if no serial number policy is selected, default > values from configuration are used. We should show that in the UI in a > similar way as for the migrate fields > > So the combo items might be: > - System default (serial number policy read from the configuration) > - Host ID > - Vm ID > - Custom > > If the System default is selected and it is Custom policy, the serial number > should be shown in the text box but could not be modified > > VM > - no need for the checkbox since selecting any other option than Cluster > default means you want to override > - no need for None option since selecting None is equivalent to Cluster > default Additionally, the "Cluster Default" choice should be "Cluster Override" in the VM. The Cluster as the default was addressed in Comment 22 Item 3. I believe we should have the None option along with the Cluster Wide option, being that they are different. I think "System Default" is confusing as well.
(In reply to Steven Rosenberg from comment #33) > (In reply to Lucia Jelinkova from comment #32) > > Few comments to the wireframes: > > > > Cluster > > - the label is too long - could it be just Serial number policy? > > - I checked the code and if no serial number policy is selected, default > > values from configuration are used. We should show that in the UI in a > > similar way as for the migrate fields > > > > So the combo items might be: > > - System default (serial number policy read from the configuration) > > - Host ID > > - Vm ID > > - Custom > > > > If the System default is selected and it is Custom policy, the serial number > > should be shown in the text box but could not be modified > > > > VM > > - no need for the checkbox since selecting any other option than Cluster > > default means you want to override > > - no need for None option since selecting None is equivalent to Cluster > > default > > Additionally, the "Cluster Default" choice should be "Cluster Override" in > the VM. The Cluster as the default was addressed in Comment 22 Item 3. I > believe we should have the None option along with the Cluster Wide option, > being that they are different. I think "System Default" is confusing as well. On second thought, for the Cluster Dialog it should be "None" for the first entry, for the VM Dialog we can have the following choices: 1. Cluster Default 2. Host ID 3. VM ID 4. Custom The width can be reduced as well to be the same width as the Custom Serial Number Text Box.
For cluster, I would use "System default" instead of None so that it is consistent with migration options. I also think it is more clear since None indicates that nothing is used but in reality the value is taken from the configuration.
(In reply to Lucia Jelinkova from comment #35) > For cluster, I would use "System default" instead of None so that it is > consistent with migration options. I also think it is more clear since None > indicates that nothing is used but in reality the value is taken from the > configuration. From what I see, Migration Policy has the following choices: 1. Auto 2. Hypervisor Default 3. Custom So it is not consistent with the Migration Policy to use the term "System Default", the later of which implies there is a system default. From what I see, if both the VM and Cluster Serial Number is not specified (None), it does not specify a Serial Number Policy from the engine point of view because the serial value is not present in the domain xml, which means the value is "None" and not "System Default". If the goal is to make the UI more user friendly (which is debatable in this case, but should be the only reason for changing the look and feel) then at least we should not mislead the user.
Created attachment 1619060 [details] v2
@Lucia I uploaded updated wireframes based off of your feedback. From a UX perspective for using "None" vs "System Default", I would use whichever term is more aligned with what's available on the back end. If there's a value that can be pulled "System Default" seems like a more appropriate and less misleading term.
(In reply to Laura Wright from comment #38) > @Lucia I uploaded updated wireframes based off of your feedback. From a UX > perspective for using "None" vs "System Default", I would use whichever term > is more aligned with what's available on the back end. If there's a value > that can be pulled "System Default" seems like a more appropriate and less > misleading term. OK, I reviewed this. "Default" is better than "System Default", though None would be more accurate at the backend. Thank you for the updates.
+1 to None
Okay so we agree that the values that can be selected at the cluster level would be None, Host ID, VM, ID, or Custom and the values that can be selected at the VM level would be Cluster Default, None, Host ID, VM ID, and Custom?
Steven, there has been a confusion about the migration fields - as you can see from my screenshots I was talking about Migration encryption not about the Migration Policy. The Migration Encryption was the first field to use the System/Cluster default values but the others are in the review now. You can see the screenshot in the gerrit: https://gerrit.ovirt.org/#/c/103542/ As for the default value vs. no value. Can you point me to the place where it is handled? I can see only one place where is the serial number handled and it is VmSerialNumberBuilder class. You can see that if vm serial number is not specified and cluster value is not specified, the configuration value is used. In case of default installation, it is HOST_ID. https://github.com/oVirt/ovirt-engine/blob/ede62008318d924556bc9dfc5710d90e9519670d/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/VmSerialNumberBuilder.java#L33 https://github.com/oVirt/ovirt-engine/blob/58593bd4f10129205eb56ba90b6893b949715109/packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql#L687 As for the VM - what is the difference between None and Cluster default?
(In reply to Lucia Jelinkova from comment #42) > Steven, there has been a confusion about the migration fields - as you can > see from my screenshots I was talking about Migration encryption not about > the Migration Policy. The Migration Encryption was the first field to use > the System/Cluster default values but the others are in the review now. You > can see the screenshot in the gerrit: > > https://gerrit.ovirt.org/#/c/103542/ > > As for the default value vs. no value. Can you point me to the place where > it is handled? I can see only one place where is the serial number handled > and it is VmSerialNumberBuilder class. You can see that if vm serial number > is not specified and cluster value is not specified, the configuration value > is used. In case of default installation, it is HOST_ID. > > https://github.com/oVirt/ovirt-engine/blob/ > ede62008318d924556bc9dfc5710d90e9519670d/backend/manager/modules/vdsbroker/ > src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/ > VmSerialNumberBuilder.java#L33 > > https://github.com/oVirt/ovirt-engine/blob/ > 58593bd4f10129205eb56ba90b6893b949715109/packaging/dbscripts/upgrade/ > pre_upgrade/0000_config.sql#L687 > > > As for the VM - what is the difference between None and Cluster default? OK yes in Migration encryption you do have System Default, but according to your explanation this would come from a configuration. In the case of the Cluster Dialog's Serial Number Policy there is no configuration, so System Default is not correct. None would describe it properly because we are not sending any serial number from the engine in the domain xml during loading in this case. If neither VM nor Cluster has a Serial Number specified, it is truly None with no default. The difference between None and Cluster Default in the VM is whether the user actually specified the Cluster or whether we default to cluster level when the user chooses None. None at the VM would allow the user to choose to not send a serial number at all thus providing more flexibility, but for backward compatibility we may consider making the default the Cluster Default while allowing the user to choose None as well. This provides more flexibility than before, because some VM's within a cluster that has a serial number policy set can still be specified as having no serial number policy. Let me know if this is clear.
(In reply to Lucia Jelinkova from comment #42) > Steven, there has been a confusion about the migration fields - as you can > see from my screenshots I was talking about Migration encryption not about > the Migration Policy. The Migration Encryption was the first field to use > the System/Cluster default values but the others are in the review now. You > can see the screenshot in the gerrit: > > https://gerrit.ovirt.org/#/c/103542/ > > As for the default value vs. no value. Can you point me to the place where > it is handled? I can see only one place where is the serial number handled > and it is VmSerialNumberBuilder class. You can see that if vm serial number > is not specified and cluster value is not specified, the configuration value > is used. In case of default installation, it is HOST_ID. > > https://github.com/oVirt/ovirt-engine/blob/ > ede62008318d924556bc9dfc5710d90e9519670d/backend/manager/modules/vdsbroker/ > src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/ > VmSerialNumberBuilder.java#L33 > > https://github.com/oVirt/ovirt-engine/blob/ > 58593bd4f10129205eb56ba90b6893b949715109/packaging/dbscripts/upgrade/ > pre_upgrade/0000_config.sql#L687 > > > As for the VM - what is the difference between None and Cluster default? Actually after looking through the code and your links, yes there is a default configuration handling after all, I was just looking at the buildVmSerialNumber function. In my testing it does not send anything however, so one could say System Default or None for that matter depending upon whether we actually set a configuration or not. None may still be a valid choice for the VM however as an override to use not the Cluster, but the configuration.
In the VM dialog, there is no other field that could "skip" cluster configuration and use the system configuration. VMs can either use cluster default value or provide its own value. Therefore I think there should not be "None" value in the VM combo box.
(In reply to Lucia Jelinkova from comment #45) > In the VM dialog, there is no other field that could "skip" cluster > configuration and use the system configuration. VMs can either use cluster > default value or provide its own value. Therefore I think there should not > be "None" value in the VM combo box. It could add for more flexibility by overriding any configuration on a per VM basis. It is a judgement call as far as whether this flexibility is added value to the user. Usually all these decisions should be coordinated with users anyway to verify it conforms with what the user actually wants. Anyway we have Laura's wire frames so we can proceed with those for now as per our meeting.
Ryan, can you please target this bug?
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Steps: 1) Create/Edit cluster with different scheduling policies 2) Check that all fields are behaving correctly and values are persistent after creating/editing 3) Do the same for VM 4) Check that cluster default in VM's scheduling policy is the same as the policy set in the cluster Results: Everything works as intended, scheduling policies can be set or changed on both cluster and VM level and are connected so that VM can use cluster values or its own and cluster uses system values or its own. Polarion test plan was created to test the functionality of the cluster and VM scheduling policies setting or editing. Verified in: rhvm-4.4.1-0.1.el8ev.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3247