Repository navigation
Migrate tools/setup-gcp to ai-on-gke/substrate-gke #2304
Description
Description
Currently, the GCP setup tools for Substrate are located in this repository under tools/setup-gcp. We propose migrating this directory and its contents to the GCP-owned repository at ai-on-gke/substrate-gke.
Rationale
- Ownership & Maintenance: The
ai-on-gkeorganization is owned and maintained by the GCP team, making it the natural, authoritative home for GCP-specific setup scripts and configurations. - Separation of Concerns: Moving cloud-specific deployment logic out of the core
substraterepository helps keep the core codebase cloud-agnostic. - Discoverability: Users looking to deploy Substrate on GKE will find all related scripts and deployment configurations consolidated in one place.
Proposed Action Items
- Port the contents of
tools/setup-gcptoai-on-gke/substrate-gke. - Update any deployment guides, READMEs, and documentation in this repository to point users to the new location.
- Delete the
tools/setup-gcpdirectory from this repository once the migration is complete. - Ensure that no existing CI/CD pipelines or automated tests are broken by this removal.
Please let me know if there are any concerns or additional steps required before we proceed with this migration!
Reacted by Benjamin Elder and Grant McCloskey
Activity
Import tools/setup-gcp from agent-substrate/substrate
Import tools/setup-gcp from agent-substrate/substrate
Import tools/setup-gcp from agent-substrate/substrate
stshrive commentedon Oct 7, 2026
As I was scoping this out, I have identified various other locations that include GCP-specific logic. I don't know that this is comprehensive yet, I will dig into it further.
maxsmythe commentedon Oct 8, 2026
Glancing through orchestrator, I don't see any cloud-specific imports. Just the transitive dependency on the installer?
stshrive commentedon Oct 9, 2026
I have done a bit of an analysis on this and I am concerned that the requisite tooling to re-inject GCP settings as to prevent major breakages is currently missing and there is no existing consensus on how to solve the problem. The fact that provider-specific tooling should be moved out is well-established as a design pattern, however there is no simple "move it somewhere else" solution available.
Finalizing this migration will require an agreement for how provider-specific settings can be articulated. There at least four possible options for this that I am aware of not all of them have support.
I am working out the details of each of those options and can update this issue once they are ready for review.
stshrive commentedon Oct 9, 2026
There is broader alignment needed on how this would end up working. The installation story itself is not well defined, so simply removing the GCP bits could land us in another suboptimal implementation of something.
Here is the proposal to make the install story more extensible
skamboj commentedon Oct 16, 2026
We run Substrate on our company’s managed Kubernetes platform. Its supported production deployment path is Helm; operators cannot normally run
ate-setup,kubectlscripts, or arbitrary installer binaries directly against production clusters.Because of that constraint, Helm would be our preferred option among the four described here.
ate-setupplus Kustomize patches remains useful for development and could provide much of the underlying implementation, but we would need to package its output ourselves before using it in production.We understand the concerns raised on #79 about requiring Helm, duplicating installation logic, and disrupting the current
koworkflow. We are not suggesting that Helm must replace those workflows. One possible model would be:koandate-setupfor development and rapid iteration.Based on our installation, it would be helpful for a generic chart to support configuration for image registries and mirrors, external PostgreSQL and object storage, trust bundles, credential providers, optional observability resources, sandbox assets, and component arguments.
A rendered manifest or an
ate-setupextension hook would still be valuable, but a supported Helm chart would make adoption substantially easier in environments where Helm is the approved deployment interface. We would be happy to contribute to or test such an installation path on our clusters.EItanya commentedon Oct 21, 2026
Steven Shriver (@stshrive) is this issue still relevant as an M3 blocker?
stshrive commentedon Oct 21, 2026
The road map I put together sets the direction we want to move in. I think it would be nice to finish this all before GA, however I think the scope is broader than the original issue uncovered and the timelines don't match up here. Based on some conversations I've had related to this work, it shouldn't be a hard blocker for M3.
EItanya commentedon Oct 21, 2026
Ok, i'm removing that milestone
tools: remove setup-gcp and hack/teardown.sh (agent-substrate#3505)
tools: remove setup-gcp and hack/teardown.sh (agent-substrate#3505)
tools: remove setup-gcp and hack/teardown.sh (#3505)