Closed sttts closed 3 weeks ago
@sttts I think up
already has all (maybe almost all?) of the functionality this would add. I also believe the functionality in up
is newer/"better" than what would be added by embedding Crossplane. See for example:
I agree broadly that it would make more sense for this functionality to live in crank
and for up
to sub package it. If that's where you're going with https://github.com/crossplane/crossplane/pull/4298 can you please raise an issue on c/c proposing this before we proceed?
This is just a PoC to show integration of both is easy. We talked about that earlier that we might want to revive crank to get more purely-in-control-plane features (think of diagnose
, composition + functions tooling etc.)
Actually, I would actually suggest to move xpkg over to crank and reimport here.
But yeah, this needs some kind of design doc, at least a one-pager. It's not super complex, so maybe a one-pager is enough to clarify the direction.
should we close this in favour of vendoring in the upstream changes, e.g. https://github.com/crossplane/crossplane/pull/4694 and https://github.com/crossplane/crossplane/pull/4271?
should we close this in favour of vendoring in the upstream changes, e.g. crossplane/crossplane#4694 and crossplane/crossplane#4271?
This is the up side. It's a different topic than promoting crank to crossplane
in upstream. Here we want to integrate the upstream command into up.
should we close this in favour of vendoring in the upstream changes, e.g. crossplane/crossplane#4694 and crossplane/crossplane#4271?
This is the up side. It's a different topic than promoting crank to
crossplane
in upstream. Here we want to integrate the upstream command into up.
Right, I was referring to vendoring the packaging functionality back into up
once it's fully introduced as crossplane xpkg
upstream like you mention above. I might just be missing a subtle difference.
not planned
Requires https://github.com/crossplane/crossplane/pull/4298.