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>
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>
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>
https://github.com/kubernetes-sigs/controller-runtime/pull/863
We'd like to use the above PR, which is not yet included in a controller-runtime
release. Updating controller-runtime requires updating a few other dependencies,
which changed the signature of client-go clientset methods. This commit removes
the only two uses of clientset from crossplane-runtime. pkg/test/integration now
uses a controller-runtime client.Client. pkg/test.Env has been removed, as it no
longer has any known users.
Signed-off-by: Nic Cope <negz@rk0n.org>
This will be the case when the referenced managed resource exists, but the field
from which we want to extract a value is empty. Consider for example a status
field that does not have a useful value until the resource has been created.
Blocking on the referenced resource field being non-zero is roughly equivalent
to blocking on the referenced resource being in condition Ready.
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>
Because we no longer include the UID of
the workload in a trait's workloadRef it
is necessary to pass the workload kind to
the trait reconciler so that we can get the
referenced workload on each reconcile and
use its UID for ensuring the corresponding
translation is controllable by it.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
In order to enable backup and restore of OAM traits
and workloads, resources they own should be able to
be regained control of if they are not already
controlled by a different owner.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
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>
We typically include the type hint at the start of enum-ish types, e.g.
AnnotationKeyFoo and ExternalResourceTagKeyBar. This was the one exception
to that pattern. Presumably this should not be noticed by most consumers of
this API, which use meta.GetExternalName to get this field.
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>
Nic Cope
Muvaffak Onus
hasheddan