Add terrajet-to-upjet migration guide #133
Conversation
| 2. Some code that will be generated by Upjet requires go1.18 or later. If you | ||
| provider's Go module declares go1.17 or smaller, you will need to update your | ||
| module's Go version, and run a `go mod tidy` to make sure that `go.mod` matches | ||
| the source code in the provider's module: |
There was a problem hiding this comment.
| 2. Some code that will be generated by Upjet requires go1.18 or later. If you | |
| provider's Go module declares go1.17 or smaller, you will need to update your | |
| module's Go version, and run a `go mod tidy` to make sure that `go.mod` matches | |
| the source code in the provider's module: | |
| 2. Some code that will be generated by Upjet requires go1.18 or later. If your | |
| provider's Go module declares go1.17 or smaller, you will need to update your | |
| module's Go version, and run a `go mod tidy` to make sure that `go.mod` matches | |
| the source code in the provider's module: |
| find . -type f -not \( -path './.git/*' -or -path './.cache/*' -or -path './.work/*' \) -exec sed -i '' 's|crossplane/terrajet|upbound/upjet|g' {} \; | ||
| ``` | ||
|
|
||
| 4. Now, you may attempt to run the Upjet's code generation pipelines: |
There was a problem hiding this comment.
| 4. Now, you may attempt to run the Upjet's code generation pipelines: | |
| 4. Now, you may attempt to run Upjet's code generation pipelines: |
| At this step, you will most probably get some compile errors. Here are some | ||
| changes that you will probably need to do, assuming the provider was | ||
| bootstrapped using Terrajet's now deprecated [provider template |
There was a problem hiding this comment.
| At this step, you will most probably get some compile errors. Here are some | |
| changes that you will probably need to do, assuming the provider was | |
| bootstrapped using Terrajet's now deprecated [provider template | |
| At this step, you will most probably get some compile errors. Here are some | |
| potential changes you need to make, assuming the provider was | |
| bootstrapped using Terrajet's now deprecated [provider template |
| You will also need to fix the referencer configurations for such managed | ||
| resources using the [resource configuration API]. |
There was a problem hiding this comment.
| You will also need to fix the referencer configurations for such managed | |
| resources using the [resource configuration API]. | |
| You will also need to fix the referenced configurations for such managed | |
| resources using the [resource configuration API]. |
There was a problem hiding this comment.
Replaced with "reference configurations" and added a link.
There was a problem hiding this comment.
I think we should also tell them to check some files in upjet-provider-template and sync with their repository. The ones that come to my mind are:
apis/generate.goto see the new statements regarding deletion/generation.cluster/provider-X/imagesfolder to integrate single image building process.- Updating the
buildsubmodule. - Checking
Makefile.
I almost wonder if we should just suggest starting from upjet-provider-template by cloning it and move their config package into that and regenerate 🤔 What do you think? It would give them the terrajet->upjet move for free along with other changes.
ulucinar
force-pushed
the
fix-832
branch
4 times, most recently
from
62dcd99
to
c34b140
Compare
|
Hi @muvaf,
Added new steps to be followed after the module migration from terrajet to upjet is done so that new upjet features can be used.
I think this is a good idea. It would make a full migration to utilize all upjet features and to publish the provider package in the Upbound marketplace (like what's been done for the https://github.com/crossplane-contrib/provider-pagerduty repo) easier. What I would suggest would be to have a module migration guide that allows more flexibility and control on the migration process with some optional steps and may be in this guide point to another guide with proper explanation, which would instruct the user to bootstrap (initial cloning) from the upjet-provider-template repo. What do you think? |
|
|
There was a problem hiding this comment.
there may be terrajet-based repos (maybe private ones) with heavily customized CI pipelines, or some new features that we enable by default in Upjet template repo like shared gRPC server, metadata extraction, doc/example generation may not be wanted/required and even not working for those providers.
Makes total sense, thanks @ulucinar !
- Discuss the Go module migration from github.com/crossplane/terrajet to github.com/upbound/upjet Signed-off-by: Alper Rifat Ulucinar <[email protected]>
Signed-off-by: Alper Rifat Ulucinar <[email protected]>
the Terrajet-to-Upjet migration guide Signed-off-by: Alper Rifat Ulucinar <[email protected]>
Description of your changes
This guide aims to help the community to migrate their Terrajet-based Crossplane providers to Upjet as Terrajet is being deprecated.
I have:
make reviewableto ensure this PR is ready for review.backport release-x.ylabels to auto-backport this PR if necessary.How has this code been tested
Tested following the guide on github.com/crossplane-contrib/provider-aws.