Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions proposals/004-skips/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# SKIP 004 - SpinKube Google Cloud

Summary: A repository for all things Google Cloud related in the SpinKube project.

Owners: Kedaar Sridhar <[email protected]>, Nick Eberts <[email protected]>, Gari Singh <[email protected]>

Impacted Projects:

- [ ] spin-operator
- [ ] `spin kube` plugin
- [ ] runtime-class-manager
- [ ] containerd-shim-spin
- [ ] Governance
- [x] Creates a new project

Created: July 22nd, 2024

## Background

Following the success of integrating SpinKube with Azure Kubernetes Service (AKS) through [SKIP 002](https://github.com/spinkube/skips/tree/main/proposals/002-skips), which resulted in the creation of an Azure-specific repository, we aim to bolster our integration efforts by expanding to Google Cloud and Google Kubernetes Engine (GKE).

After discussions with the GKE team, we have identified a strong interest in pursuing this integration to provide seamless deployment experiences for users on Google Cloud. This initiative will help increase SpinKube's visibility, usability, and adoption within the Google Cloud

## Proposal

Inspired by the successful implementation of [SKIP 002](https://github.com/spinkube/skips/tree/main/proposals/002-skips) for Azure, we propose to create a new repository under the SpinKube organization for Google Cloud called `gcp` to host any Google Cloud-specific configurations and integrations.

The `gcp` repository will contain the basic Helm chart for deploying SpinKube on GKE clusters. Additionally, it will include a marketplace-specific Helm chart for a future Google Cloud marketplace listing. The owners/maintainers of this repository will be Nick Eberts and Gari Singh from Google, along with Fermyon engineering support for this initial integration.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one area I'd like to revisit. The spinkube/azure repo did set the precedent of creating a generic SpinKube chart (basically, an 'umbrella' chart with all the necessary chart deps in place, i.e. spin-operator, cert-manager and kwasm-operator). This same setup could/would work just fine on GCP, right? If so, it'd be great to avoid following the pattern or replicating the same generic chart in every spinkube cloud-provider repo. Perhaps one solution is to break out the generic spinkube chart into a standalone repo with CI/CD to publish somewhere public (eg ghcr.io)?

However, I don't mean to block on this, since my concern isn't specific to GCP. The first version of this repo could follow the same pattern as spinkube/azure and we can always consolidate/re-org at a later date.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same setup should work for GCP. I always assumed that the later goal would be to consolidate all the top-level charts into a singular "charts" repo, as you mentioned. I think for now, the repos should be separate since there will be marketplace-specific integrations, with an eventual re-org for any top-level charts. The Google PMs are keen to get moving as well, and might have their own steps in mind for executing this integration.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for now, the repos should be separate since there will be marketplace-specific integrations

Yes, definitely agree repos should be separate per the marketplace-specific integrations. Thanks, should have clarified that.

Copy link
Contributor

@endocrimes endocrimes Jul 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did set the precedent of creating a generic SpinKube chart (basically, an 'umbrella' chart with all the necessary chart deps in place, i.e. spin-operator, cert-manager and kwasm-operator).

I think I'd continue to avoid this until we're sure of longer term direction. Partially because chart dependencies caused a lot of pain during early testing of the operator, and so letting a couple of "fewer keystroke" options evolve independently before then reconciling seems ok to me. Premature consolidation mostly reduces experimentation + evolution here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

along with Fermyon engineering support for this initial integration

This should be "SpinKube maintainers" IMO.


This repository will serve as the central hub for all Google Cloud-related work within the SpinKube project, making it easier for the community to contribute and collaborate.