Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend SSOP migration script and process with the local source #207

Merged
merged 3 commits into from
May 23, 2023

Conversation

ytsarev
Copy link
Member

@ytsarev ytsarev commented May 18, 2023

Description of your changes

Extend SSOP migration script and process with the local source:

  • Extend generate-manifests.sh to generate SSOP installation manifests
    out of local Configuration files/Compositions
  • Document it by extending existing migration step

Additionally, Comply with shellcheck:

  • Optimize grepping
  • Skip checks in places where shellcheck can't figure out dynamic eval
    and provides false negatives

Signed-off-by: Yury Tsarev yury@upbound.io

I have:

  • Read and followed Crossplane's [contribution process].
  • Run make reviewable to ensure this PR is ready for review.
  • Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

./generate-manifests.sh
Generating manifests from current cluster
export CONF_PATH=~/new-compositions
./generate-manifests.sh
Generating manifests from ./new-compositions

Checked that in both cases the script generates valid installation manifests

* Extend `generate-manifests.sh` to generate SSOP installation manifests
out of local Configuration files/Compositions
* Document it by extending existing migration step

Signed-off-by: Yury Tsarev <yury@upbound.io>
* Optimize grepping
* Skip checks in places where shellcheck can't figure out dynamic `eval`
  and provides false negatives

Signed-off-by: Yury Tsarev <yury@upbound.io>
Comment on lines 13 to 17

if [ -n "$CONF_PATH" ]; then
echo "Generating manifests from $CONF_PATH"
apiGroups=$(grep -rh apiVersion: "$CONF_PATH" | grep -E '(aws|gcp|azure).upbound.io' | sort | uniq | tr -d '[:blank:]'| cut -d ":" -f 2)
else
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @ytsarev, there might be some MRs created with monolith providers that do not belong to any configuration/composition. Therefore, getting the existing MRs from the cluster is safer before removing monolith providers.

Copy link
Member Author

@ytsarev ytsarev May 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but there might be cases when I want to migrate Composition within the Configuration code with API migrator in a fully offline mode and then generate the Provider installation manifests. Both options are not mutually exclusive and can coexist to satisfy multiple scenarios.

Signed-off-by: Yury Tsarev <yury@upbound.io>
Copy link
Member

@ezgidemirel ezgidemirel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ytsarev!

@ytsarev ytsarev merged commit 4bd2721 into crossplane:main May 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants