mbrt / k8cc Goto Github PK

Having the api-gateway in the same executable as the controller is dirty, because one cannot really do without it. For security purposes an admin could get rid of the api gateway and ask users to create their leases through kubectl (so authenticated).
The plan is to split the api-gateway away from the controller and let the first create distcc-lease objects for the second, once #8 is implemented.

We already have a DownscaleWindow field in Distcc.Spec, but we don't respect it currently. If it's present we should wait for the specified time before to do any downscale.

The Distcc CRD doesn't use the new and shiny validation provided in Kubernetes 1.9. We should do it to prevent garbage from entering the cluster.

See:

• https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation
• https://nikhita.github.io/gsoc-kubernetes-making-customresources-more-awesome

Kubernetes controllers use glog. We are currently using go-kit log. This makes the controller logs pretty crappy because two different formats are used at the same time.

We should therefore use go-kit log in the api-server only, and not in the controllers.

At the moment the operator requires the user to create the service used by distcc themselves. It would be nice if it does it automatically

Right now the fact that a user is leasing a distcc is encoded into the distcc CRD state. The state is edited by the controller, after a user asks for a lease at the API server. This is not very clean and also prevents to split the controller from the API gateway. We should instead implement something similar to the ingress resource, so split off a distcc-lease from the distcc resource.

The new package provides a code generator that should make the maintainability of the service easier

Hi @mbrt ,

I am looking for some tool that can distribute compilation/build work to multiple servers. I found distcc first, which was quite an option but I want it more "transparent"; as the result, I googled distcc with kubernetes, and found this project.

I wonder what the state of k8cc is now. If it is not totally obsoleted/deprecated, I would like to help out with this project.

Thanks in advance.

We have a busy polling in the k8cc-apiserver, while we wait for the requested objects to be updated. We should instead use the Watch interface.

We need a pod with sshd where a user can rsync their sources and compile with the distcc cluster. We need to determine how to expose it easily with a service. Maybe a node port?

It's still unclear how the user will get the compiled application back. NFS seems a bit too complicated. Maybe another rsync?

We want to have insights on how much resources are used by distcc containers, and for that there's heapster. We also want to correlate these with how long objecst take to compile. We should add a sidecar container that exposes prometheus metrics for that.

Kubernetes code generator provides some mocks that we can use to test the operators. It would be nice to add some unit tests there, because there is quite some logic there at the moment.

We currently have this kind of replies for leases:

{
    "lease": {
        "expiration": "2017-12-21T18:11:31.614953389+01:00",
        "hosts": ["distcc-master-5.distcc-master", "distcc-master-6.distcc-master"]
    }
}

Note the ugly expiration timestamp. We should truncate it to seconds (e.g. 2017-12-21T18:11:31+01:00).