Closed pipo02mix closed 6 months ago
@paurosello @calvix I would be happy if you can take a quick look since you have worked on it
We also need to mention the DNS, that there will be a new zone and anything new will be only deployed to the new DSN zone and customer will need to migrate eventually, but old DNS will work for significant time frame
more topics to cover:
more topics to cover:
* GIITOPS for wc must be turned off before migration * completely new resources for gitops after migration * mention of k8s initiator app which is not allowed for capa (it is blocked at app level,) and all config must be migrated into the configmaps to be included in the migration
@calvix Can you provide the key elements of these topics? Can be a rough outline. I'm happy to flesh it out but I don't have enough knowledge on the details for these topics.
more topics to cover:
* GIITOPS for wc must be turned off before migration * completely new resources for gitops after migration * mention of k8s initiator app which is not allowed for capa (it is blocked at app level,) and all config must be migrated into the configmaps to be included in the migration
@calvix Can you provide the key elements of these topics? Can be a rough outline. I'm happy to flesh it out but I don't have enough knowledge on the details for these topics.
GIT OPS for wc must be turned off before migration
completely new resources for gitops after migration
in vintage customer created/managed cluster via gitops using several CRs like Cluster CR,AWS Cluster CR, AWSMachine deployment, MachinedDeployment, G8sControlPlane,AWSControlPlane. In CAPI the cluster is managed only via App CR bundles and their configmaps (cluster-aws app and default-apps-aws app - which will be soon integrated into the cluster-aws app) which envelop all the CRs
the difference can be easily seen if you run kubectl gs template cluster --provider aws
compared to kubectl gs template cluster --provider capa
so the customer needs to be aware that the current resource they have for gitops management of the cluster will no longer be valid and he needs to adjust, we will provide the customer with the new resources for the gitops management as that is something that our migration tool generates and applies to the new MC
mention of k8s initiator app which is not allowed for capa (it is blocked at app level,) and all config must be migrated into the configmaps to be included in the migration
k8s-initiator-app
was used to hack-around
some limits of cluster configuration by running bash magic daemon sets which could adjust values of API server or do some magic on nodes like special taints or labels. all the features are now available and configurable via configuration of the cluster-aws values so this app is no longer needed and to avoid some weird problems we decided to completely block the app on CAPA< so it cannot be deployed, I have addressed most of the comments, still want to improve some wording and add more information
now it is ready for review
I have already all the comments PTAL
What this PR does / why we need it
Towards https://github.com/giantswarm/giantswarm/issues/29614
Things to check/remember before submitting
If you made content changes
make dev
to render and proofread content changes locally.last_review_date
in the front matter header if you reviewed the entire page.