samsung-cnct / cluster-manager-api Goto Github PK

• API accessed by a user (REST/gRPC)
• Controller(s) for SDSCluster, SDSPackageManager and SDSApplication

Breaking the application up has potential benefits:

• Easier to replace components (increased modularity)
• Easier to test (well defined contracts)
• Easier to implement security (each program can have own RBAC profile)
• Easier to implement resource management (memory, cpu, etc.)

In many places we currently just default to the default namespace. Controllers should be able to listen to all namespaces, one namespace, and possibly an array of namespaces. The namespace should be configurable

Allowing an endpoint that gives streaming updates to a cluster (or an array of clusters) would be very useful for the dashboard

• Provide prometheus data exporters
• Investigate usage of OpenTracing / Jaeger
• Provide a Grafana dashboard

• Each package needs to have a defined contract and tests
• Except generated code!

Similar to how kubernetes provides

Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}`

We should provide an API endpoint as well as binary --version support to indicate what version of our program is running.

Currently the application asks for admin privileges.
We should come up with privilege profile that is tighter.

• Indicate if the action should be retried or will always fail
• Explain why something cannot happen

Right now there are some rest endpoints to do some of this, but they were not necessarily wired up.

• Link to core technologies used: rest, grpc, custom resources, generators, controllers
• Create developer flow diagrams
• Detail packages, why they exists, names, etc
• Create CONTRIBUTING.md
• Explain how to run local environment, how to debug, how to test

When things can be controlled through a list/watch informer, they should.
Minimize looping through a "get job status" on package manager/application installation.
Re-sync shouldn't be used sparingly as it adds a tax on the system.

• Use cases
• User-level flow diagrams
• How to run the program locally and in-cluster
• How to operate the program including lifecycle management, resource allocation, security, etc
• How to submit a support request to developers

Hi! 👋

I think the aws property of AdjustClusterMsg should include credentials, data_center and instance_groups. But it has only credentials. Please take a look.

Thank you,
June Yi

Create the tests
Create sample data for the end to end tests
Check boundary issues
Create ability to simulate other moving parts, i.e. what cluster-controller may do, what a deploy-tiller job may do, etc.

Right now code will explicitly look for a cluster object and its status.kubeconfig value for the kubeconfig.
This is tight coupling and should be removed.
What happens if KrakenCluster object isn't the object that stores the kubeconfig, but rather a secret, or the field changes, etc. What happens if we support KrakenCluster and KrakenClusterV2 objects, etc.
Instead of the tight coupling there should be a representation of the cluster and methods like GetKubeconfig() should be available.
This value should be delegated / use interfaces.

Right now we do not emit any events to the object.

Looking at grpc-auth there are some great opportunities to perhaps leverage security there. Dex may also be an option.

• Each public method should have comment documentation explaining why it exists/needed
• Each package should have an explanation for what it is aiming to provide
• Comment logic inside functions as well

Right now controllers are oftening hoping for the happy path - that errors are few and far inbetween. Errors happen and our code needs to handle them.

Code should also be respectful that just as often as people create, people will delete and also likely modify. SDS[Cluster,PackageManager,Application] needs to implement the ability to delete and change.

Controllers should also be aware that all dependencies are not met and handle it correctly. Example: SDSApplication references non-ready SDSCluster and/or SDSPackageManager

• Create a Beta API specification
• Create groups so that kubectl get sds could return all sds resources
• Create proper data model validation - dependency

Currently openapi-gen creates v2 (swagger) specifications, however CustomResources require v3 specifications in order for it to serve as a validator. We should consider contributing to https://github.com/kubernetes/code-generator/tree/master/cmd/openapi-gen

This is big task and is useful for the sig-machinery group. They want to have openapi-gen support more annotations than it currently does, as well as generate the v3 compliant specifications. Doing so will help us and help the community.