* `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>
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>
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>
We could also use pkg/resource/unstructured in tests, but I think this will
require a little less boilerplate to setup tests.
Signed-off-by: Nic Cope <negz@rk0n.org>
A controller engine is somewhat like a controller "sub-manager", in that it's
effectively a group of controllers. Unlike a typical controller manager, the
lifecycle of the controllers an engine manages are not coupled to the lifecycle
of the engine itself. An engine may be used by a parent controller to start and
stop child controllers in accordance with configuration provided by the custom
resource that the parent controller watches.
Signed-off-by: Nic Cope <negz@rk0n.org>
Predrag Knezevic
Nic Cope
Dr. Stefan Schimanski
Christopher Haar
lsviben
Mateusz Puczyński
Hasan Turken
ezgidemirel
Alper Rifat Ulucinar
Bob Haddleton
Maximilian Blatt
Nic Cope
hasheddan
Muvaffak Onus
Daniel Mangum