Skip to content
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

Add Event Filtering for Notifications in Kubernetes Engine Module #1840

Closed
aminelaabi opened this issue Jan 11, 2024 · 4 comments
Closed

Add Event Filtering for Notifications in Kubernetes Engine Module #1840

aminelaabi opened this issue Jan 11, 2024 · 4 comments
Labels
enhancement New feature or request Stale

Comments

@aminelaabi
Copy link

TL;DR

The current Kubernetes Engine module lacks the ability to directly filter events when configuring cluster notifications. This can lead to increased costs when using Pub/Sub to filter events externally. To address this, I propose adding the ability to configure event filters directly within the Kubernetes Engine module.

Terraform Resources

The notification_config block supports:

pubsub (Required) - The pubsub config for the cluster's upgrade notifications.
The pubsub block supports:

enabled (Required) - Whether or not the notification config is enabled

topic (Optional) - The pubsub topic to push upgrade notifications to. Must be in the same project as the cluster. Must be in the format: projects/{project}/topics/{topic}.

filter (Optional) - Choose what type of notifications you want to receive. If no filters are applied, you'll receive all notification types. Structure is documented below.

notification_config {
  pubsub {
    enabled = true
    topic = google_pubsub_topic.notifications.id
  }
}
Copy
The filter block supports:

event_type (Optional) - Can be used to filter what notifications are sent. Accepted values are UPGRADE_AVAILABLE_EVENT, UPGRADE_EVENT and SECURITY_BULLETIN_EVENT. See Filtering notifications for more details.

https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/container_cluster#filter

Detailed design

## Proposed Feature:

**Event Filtering Options:**
Allow users to specify an input filter as a list of strings when configuring cluster notifications. The filter should support the following values:
- `UpgradeEvent`
- `SecurityBulletinEvent`
- `UpgradeAvailableEvent`

## Additional Context:

The current workaround involves filtering events externally using Pub/Sub, which can be less cost-effective. Providing a direct option to filter events within the Kubernetes Engine module would enhance usability and cost efficiency.

## Example Configuration:


module "gke" {
  source = "terraform-google-modules/kubernetes-engine/google//modules/private-cluster"
  
  # Other configuration options...

  notification_config_topic = "projects/{project}/topics/{topic}"
  filter = ["UpgradeEvent", "SecurityBulletinEvent", "UpgradeAvailableEvent"]
}

Additional information

No response

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

@aminelaabi
Copy link
Author

I'm currently working on the issue

@github-actions github-actions bot removed the Stale label Mar 12, 2024
@onuki-yoshihisa
Copy link

I am also having the same problem.
When I make changes in the UI and then try to apply terraform, the filter part comes out with the difference.

Copy link

github-actions bot commented Jul 8, 2024

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

@github-actions github-actions bot added the Stale label Jul 8, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 15, 2024
DrFaust92 pushed a commit to DrFaust92/terraform-google-kubernetes-engine that referenced this issue Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Stale
Projects
None yet
Development

No branches or pull requests

2 participants