Add design docs to kubernetes/enhancements instead of this repo

[shubheksha]

Should we consider adding them to k/e to go through the KEP process and have a single source of truth instead of this repo?

/cc @christopherhein @munnerz

[christopherhein]

I don't think it's totally necessary, with this directory I'm following a long with the CAEP format https://github.com/kubernetes-sigs/cluster-api/tree/master/docs/proposals it's also what we have in controller-runtime/designs and kubebuilder/designs

The idea here is to be pretty specific to the CAPN experience, potentially as we find areas where improvements need to happen for other projects we'll use k/enhancements

[munnerz]

I personally would be in favour of k/e simply from a visibility standpoint - whilst most CAPI providers interact with external services, this one is very kubernetes-native and relies on certain properties of the way Kubernetes works (and the assumptions we'll need to make wrt. APIs that we are syncing).

I think getting e.g. sig-api-machinery's eyes on it all would be really beneficial, and could highlight areas where we need to exercise caution around the underlying design of the syncer controller for example.

The idea here is to be pretty specific to the CAPN experience, potentially as we find areas where improvements need to happen for other projects we'll use k/enhancements

I think this works well and makes sense for our API types etc (like what we expose to CAPI), but the overarching design of syncing is something I think we would benefit from getting a 👍 from sig-api-machinery and sig-auth (especially as this is a sponsored subproject of k8s)

[munnerz]

Given the nature of the 'deployment target' (i.e. Kubernetes) I think that this project is quite cross-cutting, unlike most other CAPI providers which integrate/interact with regular ol' cloud providers.

[christopherhein]

Yeah, those are fair points @munnerz. The syncing logic would be good to get more eyes on it as we bring that code over. CAPI types are more what I was referring to since we haven't even discussed what that's going to look like. Good call 👍

[shubheksha]

I was told that WG don't have their own folders in k/e since they're sponsored by SIGs and it's upto them to decide where they docs should live. Which SIG do y'all think would be the most relevant in this case?

[christopherhein]

SIG Cluster Lifecycle is the sponsoring SIG for this since it falls under CAPI. I'd assume we'd just use that.

[vincepri]

FWIW, CAPI doesn't use k/e, at least for now. We have an issue upstream to document our process and where all our proposals are stored.

[christopherhein]

Thanks for adding that extra information @vincepri

[shubheksha]

@christopherhein @munnerz do we have consensus on moving these to k/e? I'll close this issue if so.

[christopherhein]

I don't think we do. I'm proposing we follow the CAPI style of keeping these proposals in-tree and as we get to the syncing logic + vn-agent work which will be added back in after we have the new apis done we can reconsider potentially use k/e for those.

Additional note there is a larger CAPI goal to do an overall API review when the project goes to v1beta1 I assume we'd following along with.

[christopherhein]

@shubheksha good to close?

[shubheksha]

My main motivation for moving this into k/e was higher visibility to ensure we aren't building this in a silo. I spoke with Chris offline and he shared how he's approaching this. I'll create a separate issue for a roadmap where we can track milestones and include visibility/reviews/community buy-in with it. Closing this now.