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>
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 changes APIUpdatingApplicator to make its Update call
with the object it gets rather than the one passed so that
the default behavior is a no-op rather than a guaranteed
error on mismatched resource versions.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
This will ensure resource claims don't bind to managed resources that are part
of a composite resource while these two features live side by side. I suspect it
will also nesure resource claims don't bind to a managed resource produced by a
stack. As far as I know we don't have any use cases in which a stack creates a
managed resource that is expected to be claimable.
Signed-off-by: Nic Cope <negz@rk0n.org>
This gates against two possible issues:
1. Claim A dynamically provisions managed resource M. Claim B runs and wins a
race against Claim A to bind to the newly provisioned and bindable M.
2. Claim A dynamically provisions managed resource M. Claim B explicitly sets
its resource reference to M, and is then deleted, thereby deleting M which it
was never bound to and did not dynamically provision.
Signed-off-by: Nic Cope <negz@rk0n.org>
This guards against subsequent tests failing because
they are installing the same CRDs that we being deleted.
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>
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>
Nic Cope
Daniel Mangum
hasheddan
Jared Watts
Kasey Kirkham
Muvaffak Onus