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 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>
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 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 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>
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>
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>
Previously we set the binding phase to unbound, then called Update(), which
reset the binding status to the API server value before we called
Status().Update() to persist it.
Signed-off-by: Nic Cope <negz@rk0n.org>
This commit moves where we set the finalizer for managed resources to right
before creating them, not at the beginning of the reconcile. This means we'll be
less likely to encounter issues where we can't delete a managed resource because
we could never create it in the first place, but we added a finalizer.
* By the time we get here we know our Observe call worked. If (for example) our
cloud provider credentials were completely wrong, we'd never proceed far
enough to add the finalizer.
* If Observe works but Create fails (for example because we had RO cloud
provider credentials) we would already have added the finalizer, but...
* When the managed resource was deleted we'd be able to Observe that the
external resource does not exist (because we were never able to Create it) and
thus would not call Delete on the external resource and go straight to
unpublishing credentials and removing the finalizer.
This commit also renames and refactors a bunch of our interfaces to use less
obtuse names. Previously sometimes a "finalize" method unbound a managed
resource, while at other times it removed the finalizer. Similarly, finalizers
were added in "initialize". We now have a 'Binder' interface with bind and
unbind methods, and two 'Finalizer' interfaces (one for Claim, and one for
Managed) that add and remove finalizers, as you would expect.
Signed-off-by: Nic Cope <negz@rk0n.org>
No functional updates to the code here, just tidying up the tests a bit to
ensure they all mock out their various moving parts via options.
Signed-off-by: Nic Cope <negz@rk0n.org>
We already set this reference at dynamic provisioning time, but we need it set
for (bound) statically provisioned managed resources too, so we set it
(potentially again) at binding time.
We must still set the reference at dynamic provisioning time in order to ensure
reconciles are queued for dynamically provisioned managed resources when they
become available.
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>
This commit renames "non portable resource class" back to "resource class", and
requires that resource claims reference a (non portable) resource class in any
namespace.
Signed-off-by: Nic Cope <negz@rk0n.org>
* - Introduces Initializer hook to managed reconciler.
- ManagedNameAsExternalName is introduced and used
by default by all managed reconcilers.
Signed-off-by: Muvaffak Onus <onus.muvaffak@gmail.com>
* GetExternalName and SetExternalName functions are implemented
Signed-off-by: Muvaffak Onus <onus.muvaffak@gmail.com>
* - Unit tests for ManagedNameAsExternalName struct
- Move ExternalNameAnnotationKey into meta package.
Signed-off-by: Muvaffak Onus <onus.muvaffak@gmail.com>
* Remove Establisher mechanism and port existing
establisher to Initializer.
Signed-off-by: Muvaffak Onus <onus.muvaffak@gmail.com>
* Fix claim's external name annotation propagation to
the managed resource.
Signed-off-by: Muvaffak Onus <onus.muvaffak@gmail.com>
This commit allows constant propagation of connection secrets from managed
resources to their bound resource claims. It does this by updating the existing
APIManagedConnectionPropagator to add 'propagation annotations', which can be
used by a new 'secret propagating reconciler' to watch both secrets for constant
propagation. The predicates and enqueue handler required to implement this are
included.
Signed-off-by: Nic Cope <negz@rk0n.org>
https://github.com/crossplaneio/crossplane/issues/719
The resource claim reconciler (and API definitions) consider
writeConnectionSecretToRef to be optional, but the managed resource reconciler
fails if it is not specified. This change aligns the codebase on the reference
being optional. Managed resources that do not specify a secret reference will
provision successfully without publishing their connection details to a secret.
Signed-off-by: Nic Cope <negz@rk0n.org>
https://github.com/crossplaneio/crossplane/issues/92
This returns to our historical behaviour of creating managed resources in the
namespace of thier resource class, not that of their resource claim. I believe
this pattern to be flawed, but mostly changed it in order to leverage owner
references (which cannot cross namespaces) in order to allow a claim to watch
the resources it controls.
Instead we maintain the historical behaviour for the time being, using a custom
event handler to enqueue requests for a resource's claim (reference).
Signed-off-by: Nic Cope <negz@rk0n.org>
I had previously attempted to standardise on fooReference for an ObjectReference
to a Foo, because we had a mix of fooRef and fooReference. Turns out the API
conventions document has a position on this and says we should use fooRef. I've
kept the actual Go fields named 'FooReference' for readability, but renamed the
struct tags to 'fooRef'. I've also renamed 'writeConnectionSecretTo' to
'writeConnectionSecretToRef' since it is also a reference.
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#object-references
Signed-off-by: Nic Cope <negz@rk0n.org>
Nic Cope
hasheddan
Muvaffak Onus
Daniel Mangum