Closed muvaf closed 1 year ago
I'm missing a little bit of context, is there a reason why we need to remove support for these versions?
@tnthornton It's a side effect of updating to Crossplane v1.6.0 which removed the v1beta1 versions of those CRDs altogether.
@tnthornton It's a side effect of updating to Crossplane v1.6.0 which https://github.com/crossplane/crossplane/pull/2804 the v1beta1 versions of those CRDs altogether.
Gotcha. I doubt we have many/any users of xpls working with APIs from <1.6.0. Could we maybe put a note about minimum supported versions in the README? I think as a long as we communicate it, we can move forward with the current changeset 👍
@tnthornton It's a side effect of updating to Crossplane v1.6.0 which crossplane/crossplane#2804 the v1beta1 versions of those CRDs altogether.
Gotcha. I doubt we have many/any users of xpls working with APIs from <1.6.0. Could we maybe put a note about minimum supported versions in the README? I think as a long as we communicate it, we can move forward with the current changeset 👍
@tnthornton added the note in the README. @muvaf will be at kubecon this week so we could help cut the patch release 👍🏼
Successfully created backport PR #327 for release-0.16
.
Description of your changes
up
CLI is still using the old meta API type forProvider
type which does not haveomitempty
for thespec.controller
field and this causes it to be initialized with""
and when Crossplane sees that, it tries to set the corresponding Deployment image to empty string and fails. I'm not entirely sure how we were getting away with this so far.Fixes https://github.com/upbound/up/issues/321
I have:
make reviewable
to ensure this PR is ready for review.backport release-x.y
labels to auto-backport this PR, as appropriate.How has this code been tested
Built a provider package and confirmed that when not given,
spec.controller
field does not appear in the built package.