ReferenceTo returns a pointer to an ObjectReference, which should be
avoided in favor of a more scoped reference type.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Adds a TypedReferenceTo utility function that matches the ReferenceTo
implementation for ObjectReference, but returns a TypedReference
instead.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Because the parser eventually passes a runtime.Creater and runtime.Typer
to the underlying serializer, we only require that the passed schemes
implement those interfaces, rather than require that they be
*runtime.Scheme explicitly.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Adds a package parser and a variety of backends that reads from a YAML
stream, accepting objects that are either part of the meta or object
runtime.Scheme and returning them as a Package.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Implements io.ReadCloser for afero.Fs to allow passing it to a parser
that accepts an io.ReadCloser and reads from it.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
This eliminates an extraneous assertion to metav1.Object in the Apply
method of the APIUpdatingApplicator by asserting to resource.Object at
the beginning of the function.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
This modifies the behavior of the APIUpdatingApplicator to update with
the desired object by setting its resource version to that of the
current. This ensures that a successful update will result in the object
being modified to match the desired by default. Consumers of this
Applicator no longer are required to pass in an UpdateFn to avoid no-op
updates.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
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>
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>
hasheddan