API refactor

[hunter]

Now that we have an initial prototype built, there are a few areas on the API that can be improved.

Mentioned in #15, the ThirdPartyResource may be a better approach to integrating the API. We get the benefits of Kube API Auth along with the use of etcd - https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/design/extending-api.md

(Currently a stub... updates to come)

[hunter]

Updated with some info on ThirdPartyResources

[darkcrux]

This would probably tie in with the Controller Refactor. Also removes the need for us to start our own etcd instance.

[hunter]

My current understanding of ThirdPartyResources is that only the resource is stored in etcd. For the rest of associated data it should be stored outside of that (so I assume our own etcd)

[darkcrux]

Yes. Thinking about pipelines, stages, and build info would be stored as ThirdPartyResources and it's up to the controllers to monitor the api for changes to start builds, send notifications, etc.

[hunter]

Ah yeah, I hadn't considered storing more than pipelines in there.

One thing we might need to check is if TPR is enabled in GKE

[darkcrux]

I don't think it's enabled in our latest installation.

[darkcrux]

A few things I think we need to improve on the API.

1. Create separate models for the API and the controllers. Right now the API, controller, and the datastore. So it's pretty complex. we need to simplify them.
2. breakdown the models from one big structure (pipeline contains builds contains stages) into several entries in etcd. This would pattern TPR well. Idea is when TPR is available, we can just go kubectl get pipelines, kubectl get builds, kubectl get stages, etc. It's also easier on the API side when querying.
3. remove references of datastore and scm from the api. This is a tech debt. these should be on the controller side. also make it easier to refactor the controller afterwards.

[hunter]

How will users be managed in this API? Per-user pipelines (with different auth flows for different services). Can we use the K8s user (which would probably fit the TPR model)?

[hunter]

Would it make sense to use gRPC which seems to be the trend for newer K8s Go projects? (Helm, etcd)

[darkcrux]

1. breakdown the models from one big structure (pipeline contains builds contains stages) into several entries in etcd. This would pattern TPR well. Idea is when TPR is available, we can just go kubectl get pipelines, kubectl get builds, kubectl get stages, etc. It's also easier on the API side when querying.

This would relate to the controllers too. I think it would be better for the API to have separate data structures for the pipelines, builds, and stages. The API just creates/updates them then a separate controller watches over the changes, runs the builds, then calls the API to update on the status.

When TPR is available, it'd be easier to just go and say: kubectl get {pipeline,builds,stages} etc. Not sure if kubectl create -f ... would work too.

How will users be managed in this API? Per-user pipelines (with different auth flows for different services). Can we use the K8s user (which would probably fit the TPR model)?

we could probably use the k8s user. or if not, make the user into another TPR? something like k5s-users?

[darkcrux]

Still thinking about the users.

should pipelines be linked to users? eg. 2 users accessing the same repo can have separate pipelines? which means a repo can have several hooks pertaining to a pipeline?

Our current implem doesn't have a concept of user. All the pipelines shown are created by logged in users (who have admin access to the repo) but they are shared for all users (even without repo access). Everyone can run the build.

[hunter]

This would relate to the controllers too. I think it would be better for the API to have separate data structures for the pipelines, builds, and stages. The API just creates/updates them then a separate controller watches over the changes, runs the builds, then calls the API to update on the status.

I'm wondering if builds are something that lives as a resource. Its something thats generated as part of a running a pipeline but its never edited after its finished. Would it be better to keep it in its own data store (etcd or object store)?