# Provider ID change and deprecation
**We are planning to deprecate the providerID legacy format and would like to get your opinion.**

## Background:
As we have it now, the providerID we are using has a value of the BMH UUID with the following format:

`metal3://d668eb95-5df6-4c10-a01a-fc69f4299fc6`

We found the information in this format to be problematic as it represents a BMH, not a kuberetes deployment. The limitation is apparent in operations involving some upgrade workflows in cases where the same bmh is re-used.

The solution we implemented was to introduce a new format that is both predictable and unique per Kubernetes deployment, with the following format:

`metal3://metal3/bmh-name/metal3-machie-name`

Currently, the cluster-api-provider-metal3, supports both formats, but we are planning to deprecate the old format in the near future.

## What changes are required:
Templates, such as this,, should be updated to use the new format,
Legacy: `provider-id: "metal3://{{ '{{ ds.meta_data.uuid }}' }}"`
New : `provider-id: "metal3://{{ '{{ ds.meta_data.providerid }}'` }}"

**Note: a new field, providerID, is introduced and automatically created require no action from the user, here**

## Side effects:
With this change, the node-label in the same templates has no relevance and can be omitted

node-labels: `"metal3.io/uuid={{ '{{ ds.meta_data.uuid }}' }}" `

As to timing, we can make it coincide with the next release or can be decided in future community meetings.

With that in mind, we would like to know if there are other views on the matter or issues that you think may arise due to the change.