Feat/compute filter out gke nodes #119
Open
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
…t EOL in order to avoid failure on windows systems during build process
…to avoid listing VMs belonging to GKE node pools having the same tags specified for a given policy
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.
Hi,
We recently updated the .eslintrc configuration to work with Windows end of line, issueing a yarn build command on the client folder would otherwise result in a error like the following: "Line 35:1: Delete
␍prettier/prettier".On the compute file we appended a string on the tag_filter expression to filter out compute instances belonging to one GKE cluster (node pool). This is useful in case one or more labels matching a Zorya policy are assigned both to the cluster and to the node pool. In this very specific case we noticed an error when Zorya tries to stop instances belonging to the Node Pool MIG which results in the latter destroying and recreating those instances and an overall failure in shutting down GKE cluster nodes.
The real problem is due to Zorya not being able to manage GCP MIG. The compute change_status method should not consider instances belonging to Managed Instance Group since, as I said before, "instance stop" is not possible for those VMs. We dind't find a simple way to filter out instances belonging to MIG since this information is available in the metadata field but this field is not managed (from official Google documentation) in the compute list filter options.