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

[WIP] Sync GCP fleet memberships into KRM resources #3944

Closed
wants to merge 1 commit into from

Conversation

mortent
Copy link
Contributor

@mortent mortent commented May 5, 2023

No description provided.

Copy link
Contributor

@johnbelamaric johnbelamaric left a comment

Choose a reason for hiding this comment

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

Took a quick look but more to review. Nice start :)


var (
// GroupVersion is group version used to register these objects
GroupVersion = schema.GroupVersion{Group: "config.porch.kpt.dev", Version: "v1alpha1"}
Copy link
Contributor

Choose a reason for hiding this comment

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

If these are specifically Google fleet memberships, perhaps it should be in a google group?

An alternative is to create the concept of a "K8s endpoint" or "K8s hosting service". Any cluster could meet that requirements. This controller would then simply populate those objects; other controllers could populate similar objects from other sources.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I think it is worth considering if the group is correct here, or even if we should include this controller with others in kpt/porch. This controller, like the WorkloadIdentityBinding one, is very GCP-specific.

I did think about turning this into something like a K8s endpoint style resource, but I don't think we should. The information needed to connect to different types of clusters can differ, so I think we will have a hard time making this into a proper generic resource. Even within GCP there a quite a few different types of clusters available through the Hub API: https://pkg.go.dev/google.golang.org/api/gkehub/v1#MembershipEndpoint

For hooking these resources up to the PackageVariantSet controller, we should be able to use whatever resource represent a fleet membership (or something equivalent like K8s Endpoint) since we can use arbitrary objects. But some degree of consistency might be useful.

For connecting to different types of clusters, I think we need specific code for each "hosting service' that can consume the FleetMembership resource and something equivalent for other types. Each will know what it needs from the FleetMembership-like resource and how to use that information to connect to the cluster.

But open to discussing this.

Copy link
Contributor

Choose a reason for hiding this comment

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

I could create a cloud-provider-gcp repo in Nephio. We would have this controller, plus any other integrations we do (for example the bootstrap controller integration).

)

type FleetSyncSpec struct {
ProjectIds []string `json:"projectIds"`
Copy link
Contributor

Choose a reason for hiding this comment

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

So, a fleet sync corresponds to a set of project IDs (fleet projects) from which we sync?

We would create a fleet sync to say we are interested in a particular set of fleets?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, the current implementation requires a FleetSync CR for the controller to start syncing memberships into FleetMembership CRs from the fleets in the specified projects. It might be that we could just automatically start syncing from the same project as the current cluster, but I'm not sure if that is a good solution.

}

type FleetMembershipStatus struct {
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Ideally, we would have a way to reach these, to bootstrap in config sync, etc. So a client config of some kind. Sort of like RemoteRootSync. @henderiw is working on a bootstrap controller in Nephio that will enable us to install CS and a RootSync in newly created Cluster API-based clusters. I would want to be able to integrate that with this controller.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, we can add more properties from the Fleet Membership API into the FleetMembership CRD. I've updated the PR to add Description, Labels, and State, but we can add more as needed. I'd rather start with less and add it as needed rather than syncing everything and possibly getting something wrong. There are a lot of fields available in the API.

We already have the different pieces needed to connect to clusters based on a membership, so getting that working on a controller should be pretty straightforward. I'm happy to help out on that.

@johnbelamaric
Copy link
Contributor

Oof, sorry, that's not what I intended. I was trying to rebase. I guess I did it backwards. Let me try something...but I can undo this if necessary....I think.

@johnbelamaric
Copy link
Contributor

ok. fixed. let me try this another way

@johnbelamaric
Copy link
Contributor

Superseded by #4043

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants