-
Notifications
You must be signed in to change notification settings - Fork 296
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
Migrate to Kubebuilder #66
Comments
/assigned. In progress. |
sflxn
pushed a commit
that referenced
this issue
Nov 9, 2018
Fixed the project post CRD migration. The build now works. There are a few changes in this commit, listed below. 1. Removed all unused code, scripts, and files. This includes the old controller's Dockerfile and makefile. 2. The old controller's Dockerfile and makefile have been rolled up into the top level. 3. Updated the container image name with our current registry store on GCR. 4. Made a number of changes to the CRD files under config/. 5. Modify how generate-yaml.sh works. It now calls kustomize instead of using sed. 6. Added a 'create-yaml' target in the makefile to generate the actual set of yaml files for clusterctl. Fixes #38 and #66
sflxn
pushed a commit
that referenced
this issue
Nov 9, 2018
Fixed the project post CRD migration. The build now works. There are a few changes in this commit, listed below. 1. Removed all unused code, scripts, and files. This includes the old controller's Dockerfile and makefile. 2. The old controller's Dockerfile and makefile have been rolled up into the top level. 3. Updated the container image name with our current registry store on GCR. 4. Made a number of changes to the CRD files under config/. 5. Modify how generate-yaml.sh works. It now calls kustomize instead of using sed. 6. Added a 'create-yaml' target in the makefile to generate the actual set of yaml files for clusterctl. Fixes #38 and #66
k8s-ci-robot
pushed a commit
that referenced
this issue
Nov 21, 2018
* Migration to CRDs This is a nearly buildable update of the vSphere provider to CRD. The next commit should be a clean dep ensure to populate the vendors. Once that is complete, this repo should be buildable. The update was done using kubebuilder on a separate project and then introducing those CRD updates to this repo. The provider code was updated to work with the new structure. The kustomize and clusterctl yaml config files still needs updating before this can be tested. * Updated code, scripts, makefile for CRD migration Fixed the project post CRD migration. The build now works. There are a few changes in this commit, listed below. 1. Removed all unused code, scripts, and files. This includes the old controller's Dockerfile and makefile. 2. The old controller's Dockerfile and makefile have been rolled up into the top level. 3. Updated the container image name with our current registry store on GCR. 4. Made a number of changes to the CRD files under config/. 5. Modify how generate-yaml.sh works. It now calls kustomize instead of using sed. 6. Added a 'create-yaml' target in the makefile to generate the actual set of yaml files for clusterctl. Fixes #38 and #66 * Dep ensure to get latest vendor code * Fix makefile targets and CRD rbac files 1. Cleaned up makefile. Added 3 images, production, dev, and ci. 2. Modified the CI push target to decode the service account info from Travis CI. 3. Fix up the CRD rbac files that got lost in the squashes. 4. Updated the travis CI config Resolves #79 * Fixed informers, comments, logs Fixed informers starting up. Removed commented out code and unused code. Added more logging. * Add scripts for testing in CI Added some scripts from the cluster-api-provider-gcp project that adds kubebuilder and other necessary components in CI for testing.
This was completed. #105 |
jayunit100
pushed a commit
to jayunit100/cluster-api-provider-vsphere
that referenced
this issue
Feb 26, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Cluster-API has migrated to kubebuilder and CRDs (PR kubernetes-sigs/cluster-api#494). We need to sync the vsphere cluster-api provider with the upstream changes.
The text was updated successfully, but these errors were encountered: