-
Notifications
You must be signed in to change notification settings - Fork 41
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
Multi master #47
Closed
Closed
Multi master #47
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It does not look like the PacketMachine needs a ProjectID. It is a value that we get from the PacketCluster. It is not even generated from the `make examples` file and when applied via kubectl it fails because PachetMachine.ProjectID is a required field in openapi.
…ctID remove the projectID from PacketMachine crd
update the cluster template with required fields
At the end of the story it took me an hour to understand the issue and 1 minutes to fix it. I suppose. The kubebuilder installation process is already part of the Makefile, but it was not used in CI. now it should work.
fix ci installing kubebuilder
It is cool that we cache the go dependency as a separate layer so images will take care of caching for us! But it does not come for free!!
fix ci image build test
Fix image build
The types.Machine or Cluster from v1alpha3 where not right registered to the manager
fix manager adding custerv1 schema types
fix annotations so the CRDs are correct
set correct provider ID
proper cluster reconcile loop, remove finalizers on delete
If we attempt to remove a machine that is not running on Packet (for any reason), we are in a loop where the reconciler returns 404 from Packet API and the source never gets deleted. This code should check for a 404, and it should pass forward the finalizer trigger a garbage collection. I presume we do not need to check for the number of `instances` anymore, because if they are `0` we never get over the `not found error`.
From v1alpha2 to v1alpha3 the Bootstrap.Data field got deprecated in favour of Bootstrap.DataSecretName as you can see: https://cluster-api.sigs.k8s.io/developer/providers/v1alpha2-to-v1alpha3.html#data-generated-from-a-bootstrap-provider-is-now-stored-in-a-secret
…-present trigger finalizer even if the machine is already deleted from packet
bootstrap data secret must be set
handle no ID on creation
fix packet go client wrong import
The tags generated by the machine controller where not merged with the one passed from the MachineSpec. This PR fixes the issue. Now we can use those labels to filter devices via packet api.
fix device tags
By default we mark a machine failed when it returns a status that we do not know. I think it is very reasonable. But we were not handled a few status: provisioning and queued.
get ip from control plan during cluster reconciliation
… bootstrap is not ready
add requeue timeouts for when machine cannot start because cluster or…
simplify manual install of a new cluster with make target
By default we mark a machine as failed when we receive an unrecognized state. We were not handling the `provisioning` state.
because why not?
handle device in provisioning state
bump cluster api to 0.3.5
ensure controller-gen exists and is minimum right version
…ol-endpoint move from APIEndpoint to control plane endpoint
with the userdata currently it place in this PR the master gets a running kubelet. As reported on Jira, the kubelet is not running because we do not install a CNI yet, but this is not crucial at the moment. The userdata has some fixed values that we have to remove, like the ROLE. We will get there moving forward. I would like to fix the certificate issue first
kubelet runs on master
This is the generated code required to support a PacketMachineTemplate
add support for packetmachinetemplate types
The right way to go here is via MachineSet, MachineDeployment. Those are almost the equivalent of ReplicaSet and Deployment for pod. * MachineSet represents an immutable group of Machine * MachineDeployment manage the lifecycle of MachineSet I updated our example to use those for pod rollout. By consequence the example also uses KubeadmConfigTemplate and PacketMachineTemplate Control Plane management will come in another PR.
update example to use MachineDeployment
This was referenced Jun 29, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Blocked by ENG-5450 (internal reference)