Add ability to use ConfigMap to define Device UserData and CustomData

[displague]

Device UserData and CustomData are lengthy fields that can benefit from reuse. Additionally, other Crossplane providers (provider-cloudinit), compositions, or other operators may manage the ConfigMap resources providing flexibility.

Is there a conventional format for spec.ForProvider fields that take can accept a configmap source?

The existing format is:

spec:
  forProvider:
    userdata: |
    ...

How should userdata from configmap be specified? Should this be presented as a new field?

spec:
  forProvider:
    userdataConfigMapRef:
      name: foo
      namespace: foo
      key: foo
      optional: false

Is it possible or recommended to have an alternate userdata syntax (alternate to the existing string format)?

spec:
  forProvider:
    userdata:
      valueFrom:
        kind: ConfigMap # should ConfigMap be the only resource-type? I think that's fair.
        name: foo
        namespace: foo
        key: foo
        optional: false

What pattern should be adopted for watching the specified ConfigMaps for changes? Are additional fields needed to permit a redeploy behavior on ConfigMap changes? Would this behavior conflict with the existing immutable field experience? You can not change facility, but should that be the case? What should happen if ConfigMap is changed?

The Equinix Metal API allows for changes to the Userdata and Customdata fields after deployment. This does not trigger a rebuild on the EM side. The new values can be accessed from the metadata service. These fields have utility beyond boot time.

Immutable Infrastructure

Should the Device resource take a parameter (within spec, not forProvider) that defines the behavior to take? destroy OnUserdataChange: true? Would similar fields be needed for immutable parameters like facility which can not be updated in the EM API or would changes to these fields dictate a delete+create cycle?

[displague]

@muvaf points out:

Hey! I think this could be considered similar to confidential data input where we use Secret as input. Here is an example implementation. You could reuse existing *SecretKeySelector or maybe implement it for configmaps as well.

[displague]

https://github.com/crossplane/provider-aws/blob/master/apis/database/v1beta1/rdsinstance_types.go#L457-L471 serves as an example of a field that may either be offered as string or (through use of a second field) by reference.

[displague]

Fixed in #55 Available in v0.0.7+