Revert "fix: add tolerations to Cilium Operator for cloud provider initialization taint"#1884
Conversation
…itialization taint"
There was a problem hiding this comment.
Pull Request Overview
This PR reverts a previous change that added tolerations to the Cilium Operator for handling cloud provider initialization taints. The revert removes the operator tolerations configuration that was designed to ensure the Cilium Operator could schedule during cluster initialization when nodes have the node.cloudprovider.kubernetes.io/uninitialized taint.
- Removes the operator tolerations section from Cilium configuration
- Eliminates the specific toleration for
node.cloudprovider.kubernetes.io/uninitializedtaint
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @mysticaltech, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request performs a direct revert of a previous change (PR #1882) that introduced tolerations for the Cilium Operator. The reverted change had added a specific toleration to allow the Cilium Operator to schedule on nodes that were still in the process of cloud provider initialization and thus had the node.cloudprovider.kubernetes.io/uninitialized taint. This revert effectively removes that toleration, restoring the previous behavior regarding Cilium Operator scheduling on uninitialized nodes.
Highlights
- Revert of Cilium Operator Tolerations: This pull request reverts a previous change that added specific tolerations to the Cilium Operator. The original change aimed to allow the operator to schedule on nodes during cloud provider initialization, specifically bypassing the
node.cloudprovider.kubernetes.io/uninitializedtaint.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
mysticaltech
deleted the
revert-1882-fix/issue-1879-cilium-operator-tolerations
branch
There was a problem hiding this comment.
Code Review
This pull request reverts a previous change that added a toleration for node.cloudprovider.kubernetes.io/uninitialized to the Cilium operator. The change correctly removes this configuration from locals.tf. The modification is a straightforward deletion and appears correct for its stated purpose of reverting the previous commit. I have no specific feedback on the code change itself.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
Codex Review: Here are some suggestions.
Reply with @codex fix comments to fix any unresolved comments.
About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you open a pull request for review, mark a draft as ready, or comment "@codex review". If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex fix this CI failure" or "@codex address that feedback".
| %{endfor~} | ||
| %{endif~} | ||
|
|
||
| # Operator tolerations to ensure it can schedule during cluster initialization | ||
| operator: | ||
| tolerations: | ||
| - key: node.cloudprovider.kubernetes.io/uninitialized | ||
| operator: Exists | ||
| effect: NoSchedule | ||
|
|
||
| MTU: 1450 | ||
| EOT |
There was a problem hiding this comment.
[P1] Reverting Cilium operator toleration breaks bootstrap scheduling
Removing the toleration for node.cloudprovider.kubernetes.io/uninitialized means the Cilium operator deployment again cannot schedule while new nodes are tainted during cloud controller initialization. This regression effectively reopens #1879: on fresh clusters the operator pods will remain Pending until the cloud controller clears the taint, delaying or blocking features that rely on the operator during bootstrap. Unless another change made this toleration unnecessary, the revert brings back the original scheduling failure.
Useful? React with 👍 / 👎.
Reverts #1882