* `status.observedGeneration` fields has been added to claim/composite/composed status,
showing the latest metadata.generation which resulted in either a ready state,
or stalled due to error it can not recover from without human intervention.
* `status.conditions[x].observedGeneration represents the .metadata.generation
that the condition was set based upon
Signed-off-by: Predrag Knezevic <predrag.knezevic@upbound.io>
Fixes https://github.com/crossplane/crossplane/issues/4970
These types all embed *unstructured.Unstructured. If they don't
implement their own DeepCopy methods, callers will end up calling those
of the embedded *Unstructured. The result is that a deepcopy isn't a
real copy - it's the wrong type (*unstructured.Unstructured).
Signed-off-by: Nic Cope <nicc@rk0n.org>
`spec.claimRef` schema is just subset of corev1.ObjectReference, and hence
`SetClaimReference` might get a reference that have more fields set, e.g. UID.
The fields that do not exist in claimRef schema must be not set on the underlying object,
otherwise K8s API server complains about non-existing field when client sends a patch request.
* Introduced `claim.Reference` type that corresponds to `spec.claimRef` schema.
* `composite.SetClaimReference` signature changed to accept an instance of `claim.Reference`
* appropriate tests updated/new tests added
Signed-off-by: Predrag Knezevic <predrag.knezevic@upbound.io>
Updates all core/v1alpha1 imports to the common/v1, which is the new
home of these embedded API types.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
This information is useful both for debugging XRs and XRCs, and for controllers
to watch for updates to connection details (i.e. if those details were stored in
an external system rather than in Secrets, which can themselves be watched).
Signed-off-by: Nic Cope <negz@rk0n.org>
Crossplane composite resources are cluster scoped, but they can be 'published'
to create a namespaced proxy resource. We called this resource a 'requirement',
despite it being conceptually quite similar to our existing (and deprecated)
'resource claim' concept. We've found that the 'publish a requirement' concept
has not resonated with the community and have decided to switch our terminology.
Under this new approach platform builders may choose to enable platform operators
to 'offer' (not publish) a composite resource to their platform consumers. The
namespaced interface to these composite resources will be known as a 'claim' or
'composite resource claim'. Note that we think platform builders and operators
are the key audience for these concepts; platform consumers will simply think of
themselves as using the resource as its kind indicates - e.g. 'a Kubernetes
cluster' or 'an SQL instance', not 'an SQL instance claim'.
In some cases our existing but deprecated resource claim concept has name
conflicts with this new take on the claim concept - i.e. the resource.Claim
interface. In those cases I've named the new type CompositeClaim to distinguish
it.
Signed-off-by: Nic Cope <negz@rk0n.org>
This switches names around from unstructured.Composite (for example) to
composite.Unstructured, mostly to allow several unstructured types to use
identically named options like WithGroupVersionKind. It also adds a few
getters and setters required for resource publications, and introduces the
resource.Requirement type that represents an application's requirement for a
published composite resource.
Signed-off-by: Nic Cope <negz@rk0n.org>
Nic Cope