-
Notifications
You must be signed in to change notification settings - Fork 96
chore: Deprecate make gke.
#2253
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This script seems to be unrelated to the usage of the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tech debt removal, I've asked many DENG over the years and none ever used this script.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The readme mentions using this script for testing Dataproc jobs, and I seem to recall at least trying to test some Dataproc tasks locally when doing QA for Airflow upgrades (though I don't think I managed to get it fully working at that time). In any case, since this is unrelated to GKE and we do still have Dataproc tasks in active DAGs, I don't think this script should be removed in this PR. |
This file was deleted.
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At the end of yesterday's Data Infra WG meeting @akkomar suggested that these GKE scripts could be repurposed to facilitate running Airflow local dev workloads in our own personal dev projects, which sounds like a reasonable approach to me to preserve the option to have a quicker Airflow dev process (at the cost of having to configure our own personal dev projects to allow this to work). If you agree that would be reasonable, I can contribute the necessary changes to this PR (e.g. having the scripts take a project ID argument; though since it looks tricky to pass arbitrary arguments through
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This would require each sandbox project to have a GKE cluster with Workload Identity configured with various GCP (e.g. BQ, GCS, GAR, SQL, etc.) permissions. This also means it would be each developer's responsibility to cleanup unused resources. Mozcloud lacks budget monitoring for sandbox projects, so it is hard to monitor the costs of unused resources in those projects. This is why we had For those reasons, I recommend against the solution proposed by @akkomar. If you want to re-enable the feature being removed by this PR, I'd recommend building something similar but in the supported mozcloud platform (i.e. GCPv2).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I liked the suggestion you made in Slack about potentially setting up a shared GKE cluster in a new In the meantime I'm OK with you proceeding with this PR since the GKE scripts no longer work as is. However, I have squirreled away revised versions of the GKE scripts in the GKE-sandbox-config branch just in case someone like me or @gleonard-m ends up needing to resort to using a custom GKE sandbox setup. |
This file was deleted.
This file was deleted.
Uh oh!
There was an error while loading. Please reload this page.