Nic Cope
Whoops - good catch. I always look at events now so I didn't even notice. I think there's a simpler fix for status conditions specifically per #292. That won't cover...
> I don't think that is a pattern I've seen yet. We noted in https://github.com/crossplane/crossplane-runtime/pull/292#issuecomment-921777252 that this pattern does in fact exist, at least in some AWS and Azure controllers....
> We could possibly expand resource.Managed interface to have GetStatus() runtime.Object and SetStatus(runtime.Object) and then DeepCopy the status before the update operation and later call SetStatus on the returned object...
Despite the guidance around the status field's "recreatability" being relaxed per https://github.com/kubernetes/enhancements/pull/2537 I think we should be warning folks to update status (or really any part of the managed resource)...
> FYI, this causes reconciler to drop any status update made in Observe before the first successful Create call. I'm working through this today, trying to determine how much of...
> The case I'm referring to is where we have to return ResourceExists: false because creation actually failed (even though external.Create succeeded in earlier reconcile) and needs to be retried....
I believe we can solve this somewhat systemically if crossplaneio/crossplane#593 is merged. If requeue logic becomes a function of the error returned by CRUD operations then we can [assert whether...
I still feel strongly that this is not a wise path. I posted a related comment over on https://github.com/crossplaneio/stack-gcp/issues/157#issuecomment-585379488. I do think we should: * Ensure resource claims provide clear...
Part of me is eager to draw people's attention to the new feature and wants to update every example of P&T to have a `function-patch-and-transform` equivalent (maybe in a tab)....
Default values are only set at create time. They don't apply retroactively to existing claims. It's better to think of them as default initialization values. As @phisco mentions, this is...