Comment 5 for bug 1884157

Why this unique constraint is introduced in 3.3? It is breaking some users' use case. Like the following, a 3.2 maas had no problem dealing with duplicated IPMI IP, and then when it is migrated to 3.3, db migration crashes.

Applying auth.0006_default_auto_field... OK
Applying maasserver.0277_replace_nullbooleanfield... OK
Applying maasserver.0278_generic_jsonfield... OK
Applying maasserver.0279_store_vpd_metadata_for_nodedevice... OK
Applying maasserver.0280_set_parent_for_existing_vms... OK
Applying maasserver.0281_secret_model... OK
Applying maasserver.0282_rpc_shared_secret_to_secret... OK
Applying maasserver.0283_migrate_tls_secrets... OK
Applying maasserver.0284_migrate_more_global_secrets... OK
Applying maasserver.0285_migrate_external_auth_secrets... OK
Applying maasserver.0286_node_deploy_metadata... OK
Applying maasserver.0287_add_controller_info_vault_flag... OK
Applying maasserver.0288_rootkey_material_secret... OK
Applying maasserver.0289_vault_secret... OK
Applying maasserver.0290_migrate_node_power_parameters...Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "maasserver_bmc_power_type_parameters_idx"
DETAIL: Key (power_type, md5(power_parameters::text))=(ipmi, fc8ed3c5711cc12878b8bf8360674799) already exists.