In MigPlan resource now spec.persistentVolumes.supported.copyMethods is mandatory, and when pv: true the migration_run role does not set the right values. It makes the automation fail with this error
TASK [migration_run : Update migration plan with PVs] **************************
fatal: [localhost]: FAILED! => {"changed": false, "error": 422, "msg": "Failed to patch object: {\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"MigPlan.migration.openshift.io \\\"mssql-app-migplan-1573635395\\\" is invalid: spec.persistentVolumes.supported.copyMethods: Required value\",\"reason\":\"Invalid\",\"details\":{\"name\":\"mssql-app-migplan-1573635395\",\"group\":\"migration.openshift.io\",\"kind\":\"MigPlan\",\"causes\":[{\"reason\":\"FieldValueRequired\",\"message\":\"Required value\",\"field\":\"spec.persistentVolumes.supported.copyMethods\"}]},\"code\":422}\n", "reason": "Unprocessable Entity", "status": 422}
This PR fixes this issue. Instead of creating a new plan, it takes the plan that the controller has created and follows these steps:
Modifies the "metadata" section so that the MigPlan can be updated (removes creationTimestamp, uid, resourceVersion...)
Removes the "status" attribute
Modifies only the part regarding the volumes, "persistentVolumes", and only the part of the volume that it wants to modify. That way it doesn't modify anything else added/removed by the controller.
This way, if there are further changes in any other parts of the MigPlan structure, it will not impact the PV automation unless it changes directly the PV section that needs to be modified.
Apart from that, it includes a change to allow the migration of multiple namespaces at once, and export the variable "fact_migrated_plan" so that testcases can verify the existence (or not) of warnings and critical conditions.
In MigPlan resource now
spec.persistentVolumes.supported.copyMethodsis mandatory, and whenpv: truethe migration_run role does not set the right values. It makes the automation fail with this errorThis PR fixes this issue. Instead of creating a new plan, it takes the plan that the controller has created and follows these steps:
This way, if there are further changes in any other parts of the MigPlan structure, it will not impact the PV automation unless it changes directly the PV section that needs to be modified.
Apart from that, it includes a change to allow the migration of multiple namespaces at once, and export the variable "fact_migrated_plan" so that testcases can verify the existence (or not) of warnings and critical conditions.