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>
Updates controller-runtime and pins k8s dependencies to v0.18.6, which
is used by controller-runtime for the v0.6.2 release.
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>
hasheddan
Nic Cope
Daniel Mangum
muvaffak onuş
Jared Watts
Kasey Kirkham