* `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>
`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>
This updates the controller-runtime and all of its dependencies to the
latest release.
This includes a bunch of changes which break backwards compatibility
introduced by controller-runtime 0.7.0 and 0.8.0, for example:
> A number of methods that previously took runtime.Object & internally
> type-asserted them to metav1.Object now take client.Object (for non-list
> objects) or client.ObjectList (for lists). The practical upshot of this
> is more type-safety and clarity around what's required for particular
> methods.
> All concrete API types (anything that implements runtime.Object & has
> a metadata field) already implement client.Object or client.ObjectList,
> so practical impact should be limited to folks who pass around
> runtime.Object values instead of concrete types.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
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>
https://github.com/crossplane/crossplane/issues/1755
This removes support for the secret propagation and target controllers that each
Kubernetes Cluster managed resource implemented before workloads were deprecated.
See the above issue for context.
Signed-off-by: Nic Cope <negz@rk0n.org>
This field distinguishes credentials configuration from other (currently
hypothetical) aspects of provider configuration. It also introduces a
'spec.credentials.source' field that can be used to determine which credentials
source the provider intends to use.
Signed-off-by: Nic Cope <negz@rk0n.org>
This cocndition indicates that a ProviderConfig is being deleted, but blocking
because it still has users. The condition mirrors the similar PVC condition.
There is no inverse of 'Terminating', because a ProviderConfig cannot recover
from the condition.
Signed-off-by: Nic Cope <negz@rk0n.org>
Credentials secrets are used by ProviderConfigs. They should be optional, since
a ProviderConfig may use a form of authentication that does not involve secrets.
This is a breaking API change, though I believe this interface was orphaned and
not actually in use anywhere.
Signed-off-by: Nic Cope <negz@rk0n.org>
This commit adds a reconciler and some utiltiies that allow Crossplane providers
to track the usage of their ProviderConfig resources. To do so, a provider must:
* Apply a ProviderConfigUsage each time a managed resource successfully connects
to its external API using a ProviderConfig (or is reasonably expected to be
about to do so). The Apply should be a no-op if there is an existing
ProviderConfigUsage for the managed resource - the IsNotAllowed ApplyOption
may be used to establish this.
* Start a controller that watches for ProviderConfigs and ProviderConfigUsages
using the supplied providerconfig.Reconciler.
Signed-off-by: Nic Cope <negz@rk0n.org>
https://github.com/crossplane/crossplane-runtime/pull/186
This change should have been included in the above PR; composite resources
no longer have a reclaim policy and instead are immediately deleted when
their claim (nee requirement) is deleted.
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 interface represents a resource with a deletion policy; i.e. a resource
whose underlying external resource may either be deleted or orphaned when the
it is deleted.
Signed-off-by: Nic Cope <negz@rk0n.org>
The deletion policy is a more narrowly scoped variant of the reclaim policy. It
affects only whether exeternal resources are deleted or orphaned when their
corresponding managed resource is deleted, as opposed to the reclaim policy
which also affects whether the managed resource is deleted when its bound claim
is deleted.
Signed-off-by: Nic Cope <negz@rk0n.org>
Provider reference is a required field for types that embed it. In
practice, accessing the Name field of a Provider reference should never
result in a nil pointer dereference, but it is still an unsafe
operation. Changing the Provider reference to a non-pointer absolves the
user from checking for a nil reference each time it is used.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
We are currently using corev1.ObjectReference for provider resources.
This includes more information than needed and encourages
using helper methods that may depend on other fields in the type that we
do not intend to be utilized. This updates provider references
fields to use the Reference type, which only has a name field.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
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>
This commit introduces managed.APISimpleReferenceResolver, which satisfies the
managed.ReferenceResolver interface. This variant requires much less plumbing
and reflection because it expects that managed resources expose a single
ResolveReferences method that will optionally select and then resolve any
resource references. It also adds a new pkg/reference which contains a library
that managed resource authors _may_ choose to use to avoid reimplementing common
reference selection and resolution logic.
The existing managed.APIReferenceResolver implementation remains the default,
but is marked deprecated and will be removed once all managed resources use the
APISimpleReferenceResolver. Notably, the "reference resolution" condition is no
longer set by managed.Reconciler - managed resources will report reference
resolution issues via the Synced condition (i.e. as a ReconcileError).
Signed-off-by: Nic Cope <negz@rk0n.org>
This allows us to require that name (and namespace where appropriate) are set at
the CRD level. In the case of cluster scoped resources that reference secrets
this is less surprising than defaulting to the `default` namespace when the
namespace is omitted.
Signed-off-by: Nic Cope <negz@rk0n.org>
This commit renames "non portable resource class" back to "resource class", and
requires that resource claims reference a (non portable) resource class in any
namespace.
Signed-off-by: Nic Cope <negz@rk0n.org>
Predrag Knezevic
Nic Cope
Christopher Haar
lsviben
Hasan Turken
ezgidemirel
Bob Haddleton
Maximilian Blatt
Nic Cope
Sascha Grunert
hasheddan
Muvaffak Onus
Daniel Mangum