add support for userdata from configmap references

[displague]

This PR has a few incomplete changes to incorporate for #54:

• support for Metros
• support for userdataRef to load device userdata from configmaps and secrets
• updates the upbound build/ submodule (and make run)

TODO:

• how should userdata changes trigger the device to reprovision? Should this be indicated with spec level (not forProvider level) options? Document best practice for external resource updates that require delete + create crossplane/crossplane#2258

  Update: this is less destructive with POST /devices/{id}/actions { "type": "reinstall" } https://metal.equinix.com/developers/docs/resilience-recovery/reinstall/

[displague]

I don't think we should modify UserData in spec like this, this is acting like a late initialization.

Ultimately, either userdata or userdataRef should be provided.

[muvaf]

I'd suggest having a way to differentiate between the kinds, i.e. Secret and ConfigMap, this reference can point to because names are unique at kind level, so there might be unexpected results if there is ConfigMap and Secret with same name and namespace.

For references, we usually go for FieldNameKindRef, like UserDataSecretRef and/or UserDataConfigMapRef.

Another way could be to go for discriminator field, like kind field in DataKeySelector:

// DataKeySelector defines required spec to access a key of a configmap or secret
type DataKeySelector struct {
	NamespacedName `json:",inline,omitempty"`
	// +kubebuilder:validation:Enum=Secret;ConfigMap
	Kind           string `json:"kind"`
	Key            string `json:"key"`
	Optional       bool   `json:"optional,omitempty"`
}

[muvaf]

You can use reference resolver mechanism from crossplane-runtime that will take care of this before your functions are called. See an example here.

[displague]

@muvaf It looks like reference.Resolve can only work with cluster scoped resources because the Reference field wants a *xpv1.Reference (name only). Perhaps that could be modified to an interface in the future to accommodate SecretReference, TypedReference, and others. I think a TypedReference is what I would use here.

[muvaf]

Ah that's true! It's designed for finding other managed resource.

[displague]

how should userdata changes trigger the device to reprovision? Should this be indicated with spec level (not forProvider level) options? crossplane/crossplane#2258

There are parallels to this question in packethost/terraform-provider-packet#77 where the intent to reprovision an existing device is desired, without DELETE'ing the resource. Some otherwise immutable features become mutable through EM API /device/{id}/actions.