Provider ID change and deprecation
Ádám Rozmán
Hi,
I'd
like to inform the community about a planned change related to the providerID
in metal3.
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 soon.
What changes are required:
Templates, such as this, should be updated to use the new format,
L
egacy: 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.
Best Regards,
Adam
Zane Bitter
>
> Hi,
>
>
> I'd like to inform the community about a planned change related to the
> providerID in metal3.
>
> like to get your opinion.*
>
>
> <https://hackmd.io/FcFUh01vSJ2ANmFpzd3Ung?view#Background>
>
> 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
>
> |
hadn't previously used it) so solve the problem that if a BMH was
deleted and re-added, it could get re-associated with an existing Node
that was in fact gone:
https://github.com/openshift/cluster-api-provider-baremetal/pull/113/commits/0c93e102b01aa564da8406404e7a760d77c669dc
So I'd be curious to know why CAPM3 is going in the opposite direction
:) The fact that we do upgrades in-place is likely one big difference.
> We found the information in this format to be problematic as it
> represents a BMH, not a kuberetes deployment.
onto a particular host. In the v2 API proposal the UID of the
'deployment' resource would be a good candidate, but in the meantime
there's nothing ideal in the BMH API.
> 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
>
> |
I'm a bit concerned that only names appear in the id though, because
names are not unique across either namespaces or time.
> Currently, the cluster-api-provider-metal3, supports both formats, but
> we are planning to deprecate the old format soon.
>
>
>
> What changes are required:
>
> Templates, such as this, should be updated to use the new format,
>
> L
>
> egacy: |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*
>
>
> <https://hackmd.io/FcFUh01vSJ2ANmFpzd3Ung?view#Side-effects>
>
> 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.
>
>
> Best Regards,
> Adam
>
> You received this message because you are subscribed to the Google
> Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to metal3-dev+...@googlegroups.com
> <mailto:metal3-dev+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/DU0P189MB2273B6149A595212BF79546E8EAD9%40DU0P189MB2273.EURP189.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/metal3-dev/DU0P189MB2273B6149A595212BF79546E8EAD9%40DU0P189MB2273.EURP189.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.