[pve-devel] [RFC PATCH manager] migrate: fix conntrack migration and ha-resources checkbox

[Thomas Lamprecht]

Am 01.08.25 um 09:11 schrieb Daniel Kral:
> Thanks for spotting that!
> 
> On Fri Aug 1, 2025 at 8:38 AM CEST, Thomas Lamprecht wrote:
>> Am 31.07.25 um 17:58 schrieb Gabriel Goller:
>>> +                console.warn(`failed to query /capabilites/qemu/migration on '${target}':`);
>>> +                console.warn(err);
>>>              }
>>>  
>>>              me.fetchingNodeMigrateInfo = false;
>>> @@ -447,7 +448,7 @@ Ext.define('PVE.window.Migrate', {
>>>              }
>>>  
>>>              let comigratedHAResources = migrateStats['comigrated-ha-resources'];
>>> -            if (comigratedHAResources !== undefined) {
>>> +            if (comigratedHAResources !== undefined && typeof comigratedHAResources[Symbol.iterator] === 'function') {
>>
>> If it exists this is always an array per the schema though,
>> so the following might be enough:
>>
>> if (typeof comigratedHAResources === 'array') {
>>
>> Or use the ExtJS frameworks' Ext.isIterable() while under the hood it's a bit more
>> heuristic than your check, it should cover all (for us) relevant cases
>>
>> if (Ext.isIterable(comigratedHAResources)) {
>>
>> Your variant might be fine as Proxmox.Utils method though, but rather overkill for
>> now.
> 
> Another even simpler version that we use in the function already (e.g.
> right above for blockingHAResources) is to just fallback to an empty
> array, i.e.
> 
> let comigratedHAResources = migrateStats['comigrated-ha-resources'] ?? [];
> if (comigratedHAResources.length) {
> ...

FWIW, the backend is wrongly setting this to an object by default, that
might contribute to the error here, or even be its actual source!

I'm fixing this up there and will also do a s/comigrated/dependent/ as
that's what this actually describes, that these resources then normally
also migrate is the result not the cause, and might change with node
affinity rules being mixed with non-strict resource once in the future.

> 
> 
> Either way, the fix should also be done for checkLxcPreconditions(...),
> because there it's missing the check too.
> 
Will also take another look at the backend here.