andrijapanicsb opened a new pull request, #14532:
URL: https://github.com/apache/cloudstack/pull/14532

   ### Description
   
   **In short:** the VM import form has a switch that decides what happens when 
an imported NIC's MAC address is already used on the selected network. Its 
label and tooltip did not say that. This PR renames it to **"Generate new MAC 
address if already in use"**, gives it a plain tooltip, and hides it where it 
has no effect. UI only.
   
   **Why it matters:** an operator importing a VMware VM into KVM sees a switch 
called "Allow duplicate MAC addresses". Turning it on does the opposite: 
CloudStack replaces the conflicting MAC with a new one. On the other import 
screens the same switch is just called "Force". On remote KVM and QCOW2 disk 
imports it does nothing, because the server always generates a new MAC there.
   
   | Import screen | Before | After |
   |---|---|---|
   | VMware → KVM (cold and warm) | "Allow duplicate MAC addresses" (wrong: it 
replaces the MAC) | "Generate new MAC address if already in use" |
   | KVM unmanaged, VMware unmanaged | "Force" | "Generate new MAC address if 
already in use" |
   | Remote KVM | "Force", ignored by the server | Hidden |
   | QCOW2 from local/shared storage | "Force", ignored by the server | Hidden |
   
   New tooltip on every screen where the switch is shown:
   
   > If a NIC's MAC address is already used by another NIC on the selected 
network, CloudStack assigns a new MAC address to the imported NIC and the 
import continues. When this is off, the import fails instead. Guest network 
settings or licenses tied to the old MAC address may stop working.
   
   No API or backend change. Where the switch is still shown, the `forced` 
parameter is sent exactly as before. On the two screens where it is now hidden, 
the server already ignored it.
   
   <details>
   <summary>Details</summary>
   
   - `ui/public/locales/en.json`: two new keys, 
`label.generate.new.mac.if.in.use` and `message.generate.new.mac.if.in.use`.
   - `ui/src/views/tools/ImportUnmanagedInstance.vue`: both `forced` switches 
use the new label and tooltip. The tooltip now comes from a UI string instead 
of the `forced` API parameter description. The switch in the non-VMware row is 
hidden when `isExternalImport` or `isDiskImport` is true.
   - Server code that ignores `forced` on the hidden screens, in 
`UnmanagedVMsManagerImpl`:
     - remote KVM: `importExternalKvmVirtualMachine` calls `importNic(..., 
true)`
     - disk import: `importKvmVirtualMachineFromDisk` calls 
`networkOrchestrationService.importNic(..., true)`
   - `label.allow.duplicate.macaddresses` and `label.forced` are left in place; 
`label.forced` is used by other forms.
   - Other languages fall back to English for the two new keys.
   
   </details>
   
   ### Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [x] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   - [ ] Build/CI
   - [ ] Test (unit or integration test code)
   
   ### Feature/Enhancement Scale or Bug Severity
   
   #### Bug Severity
   
   - [ ] BLOCKER
   - [ ] Critical
   - [ ] Major
   - [x] Minor
   - [ ] Trivial
   
   ### Screenshots (if appropriate):
   
   <!-- before / after screenshots from a live environment -->
   
   ### How Has This Been Tested?
   
   - ESLint on `ImportUnmanagedInstance.vue`: no errors.
   - `en.json` parses and has no duplicate keys.
   - Label and tooltip rendered with the same Ant Design Vue version (3.2.20) 
at the form widths of 1920, 1366, 1024 and 768 px screens. The label always 
fits on one line. On a ~1024 px screen, in the KVM row, it moves below "Migrate 
allowed" instead of sitting next to it.
   - Not yet checked on a running management server.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to