Common api #37
Common api #37
Conversation
|
Issues linked to changelog: |
api/core/v1alpha1/core.proto
Outdated
|
|
||
| package core.skv2.solo.io; | ||
|
|
||
| option go_package = "github.com/solo-io/skv2/pkg/api/core.skv2.solo.io/v1alpha1/types"; |
There was a problem hiding this comment.
not sure i agree with the choice of v1alpha1 for the version for core types.
also, what's the reasoning using a types package rather than a package named for the api version?
There was a problem hiding this comment.
Why no v1alpha1, using the versioning just allows us to make breaking changes to the API without having to make breaking changes to the code. As we support more APIs, and potentially multiple versions of those APIs, following kubernetes versioning for our APIs will become more and more useful.
I will delete the types package
api/core/v1alpha1/core.proto
Outdated
|
|
||
| string name = 3; | ||
|
|
||
| string namespace = 4; |
api/core/v1alpha1/core.proto
Outdated
| FAILED = 3; | ||
|
|
||
| // Finished processing successfully. | ||
| ACCEPTED = 4; |
There was a problem hiding this comment.
i'm not sure about making State a core api in skv2 yet. i think it's worth discussing at least
| @@ -0,0 +1,60 @@ | |||
| package main | |||
There was a problem hiding this comment.
we already have some code generation in skv2 for multicluster; maybe this belongs alongside that?
There was a problem hiding this comment.
We have templates to generate multi cluster reconcilers, but I don't think we have code to specifically generate code in this repo to be consumed by other repos, I may be wrong though.
| */ | ||
| message KubernetesClusterSpec { | ||
| // name of the secret which contains the kubeconfig with information to connect to the remote cluster. | ||
| string secret = 1; |
There was a problem hiding this comment.
i'd like to allow the user to provide a secret_key here as well. we can override emtpy with a default
There was a problem hiding this comment.
What do you mean by a secret_key
There was a problem hiding this comment.
I think he means the key of the kubeconfig entry in the secret.
kind: Secret
metadata:
...
data:
<cluster.secret_key | "some-default">: encoded_kubeconfig
| // version of kubernetes | ||
| string version = 2; | ||
| // cloud provider, empty if unknown | ||
| string cloud = 3; | ||
|
|
||
| string region = 4; | ||
|
|
||
| string zone = 5; |
There was a problem hiding this comment.
are any of these other fields used anywhere? how are they intended to be consumed?
No description provided.