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>
The claim controller in Crossplane core is the only place this machinery is
still used, so it will be migrated into that controller.
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 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>
This allows users of the MustBeControllableBy ApplyOptions to determine how to
handle the case in which a resource cannot be applied because it is not
controllable - e.g. to abort the apply operation without returning an error.
Signed-off-by: Nic Cope <negz@rk0n.org>
This updates the AsOwner and AsController to use TypedReference, which
is a more scoped version of ObjectReference that still contains all
necessary fields to create a controller or owner reference for an
object.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
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>
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>
Add an UpdateFn wrapper around ApplyOption that simplifies
the interface for passing a mutating function to
APIUpdatingApplicator.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
This is effectively identical to the existing ManagedConnectionPropagator, but
propagates from any ConnectionSecretOwner, rather than requiring the much larger
and more specific Managed interface. This allows this propagator to be used to
propagate from managed resources to claims and also from composite resources to
requirements.
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>
This allows propagation to function even when the propagating and/or propagated
secrets have been deleted and recreated, and thus allocated new UIDs.
Signed-off-by: Nic Cope <negz@rk0n.org>
This is roughly the same functionality as controllerutil.CreateOrUpdate, albeit
a little simpler. This variant is useful to us because it satisfies our
Applicator interface.
The key difference between the patching and updating applicators is that the
patching applicator will leave any existing, unset fields untouched (to the
extent that a JSON merge patch allows), while the updating applicator will
always update any existing object to exactly match the desired object.
Signed-off-by: Nic Cope <negz@rk0n.org>
This allows resource claims and managed resources to adopt existing orphaned
connection secrets without needing to be concerned with the fact that they
might be adopting an existing secret that is unrelated to Crossplane.
Signed-off-by: Nic Cope <negz@rk0n.org>
This option replaces ControllersMustMatch. It works slightly differently in that
it takes the expected controller UID explicitly instead of inferring it from the
desired object, and considers current objects with no controller reference to be
controllable. Presumable objects with no controller reference will be adopted.
Signed-off-by: Nic Cope <negz@rk0n.org>
The Apply method of the resource.Applicator interface took a client.Client
largely because it was extracted from the pre-existing resource.Apply function
to allow pluggable Apply implementations. Now that we have types that satisfy
resource.Applicator it makes more sense for those types to include a client,
rather than being passed one for every Apply call.
Signed-off-by: Nic Cope <negz@rk0n.org>
Getting, creating, or patching an object using the controller-runtime client
updates said object with the latest state from the API server. This commit
alters our resource.Apply logic to patch 'into' the supplied object, not a
deepcopy of that object. This ensures the object passed to apply is updated
with the latest view from the API server, whether it is created or patched.
Signed-off-by: Nic Cope <negz@rk0n.org>
I'm hoping this will help us pass in loggers and eventers using variadic options
without awkward names like WithClaimBindingReconcilerLogger. This is a huge diff
but there's no functional changes - only moving things around and renaming them.
I was hoping we'd be able to do with without a breaking API change by using type
aliases, but doing so would create cyclic imports, because the new reconciler
packages depend on the resource package, which is where we'd need to create the
type alias to the reconciler packages.
I've broken up api.go (which contained most of the 'Kubernetes API' - i.e.
default - implementations of most of the pluggable interfaces used by our
reconcilers) into several files. My heuristic here was:
* If the implementation is used by a single reconciler, put it in that
reconciler's package.
* If the implementation is used by more than one reconciler, put it in the
resource package.
Signed-off-by: Nic Cope <negz@rk0n.org>
This commit changes the meaning of the resource claim resource policy to match
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming as
closely as possible, minus the deprecated 'Recycle' policy. Previously the
reclaim policy dictated only what happened to the external resource when its
managed resource was deleted.
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>
Jared Watts
Nic Cope
Dr. Stefan Schimanski
Christopher Haar
Hasan Turken
Aditya Sharma
Nic Cope
Alper Rifat Ulucinar
Sascha Grunert
Muvaffak Onus
hasheddan