Addition of a KubeLatentWorker #3155
Conversation
|
@Zempashi I have not looked the PR in details yet, but a first comment come to my mind. This is using the python binding for kubernetes REST api. Most of the time, Buildbot only needs one or two REST api calls, and it is eventually much simpler to just use the REST api directly. This is how MarathonLatentWorker is implemented, and I think it is much easier to develop and test, using httpclientservice. |
Zempashi
force-pushed
the
KubeLatentWorker
branch
from
677a0c4
to
65115cf
Compare
|
Agree, I'll do this |
Zempashi
force-pushed
the
KubeLatentWorker
branch
from
65115cf
to
a66539f
Compare
| defer.returnValue(res) | ||
|
|
||
| @defer.inlineCallbacks | ||
| def recursive_render(self, obj, props): |
There was a problem hiding this comment.
This would be so much simpler if we would just use the REST api.
We would just use json like objects that are already deeply renderable.
| cls.dependency_error() | ||
| job_name = '%(prop:buildername)s-%(prop:buildnumber)s' | ||
| return client.V1Job( | ||
| metadata=client.V1ObjectMeta(name=job_name), |
There was a problem hiding this comment.
again, here we replace client.*( by dict( and we don't use the unneeded typing system from the python binding.
If we make typing error, the error will be at runtime as well, but done by the k8s server instead of the python binding. That does not make much of a difference.
There was a problem hiding this comment.
For now, I have a couple of call : create_namespace_job and delete_namespace_job.
But this call create job and job created pods (docker containers). That's how kubernetes handle short live container
That's also why I miss the stop_container(fast=False) and followStartupLogs. I need to find pod from a job.
This would use list_namespaced_pod (https://github.com/kubernetes-incubator/client-python/blob/master/kubernetes/docs/CoreV1Api.md#list_namespaced_pod) (with long polling to wait for pod creation or deletion).
'FollowStartupLog' needs read_namespaced_pod_log (https://github.com/kubernetes-incubator/client-python/blob/master/kubernetes/docs/CoreV1Api.md#read_namespaced_pod_log) with streaming capabilities.
I don't have any other feature in minds (may be managing password with 'secrets'), but each would add a bunch of call. This is basically redevelopping the python client.
But again, I agree the render thing is really ugly. I've read somewere that the python client can also take yaml string (need to figure out how). The string would be renderable by default, without the hassle of developping each call.
There was a problem hiding this comment.
I'll do as you want:
- trying string with the kubernetes client
- pure http call
master/docs/relnotes/index.rst
Outdated
| @@ -10,6 +10,48 @@ Release Notes | |||
|
|
|||
| .. towncrier release notes start | |||
|
|
|||
| Buildbot ``0.9.6-35-gfb26e170d`` ( ``2017-04-27`` ) | |||
There was a problem hiding this comment.
You need to make sure not to commit that file.
There was a problem hiding this comment.
Arghh.
It keeps adding to the commit index (I don't do commit -a or else). Do you know why ?
Surely because I run make -C master/docs SPHINXOPTS=-W spelling to compile docs
Does another command exists ?
Zempashi
force-pushed
the
KubeLatentWorker
branch
from
a66539f
to
65aa92f
Compare
I added a kubernetes Latent Worker to buildbot.
This is not done yet.
The Kubernetes API is quite large, I don't want to add a parameter for each possibility (volume, secrets, service-account, etc...), so I went with the all API offered by the python client, adding a layer to render variable that comme from buildbot. This could be arguable, I'm happy to discuss.
I would like early review for the direction to take on this.
Before be ready to merge I need to develop the stop_instance(fast=False) and everything else you tell me.
I agree for more unit test, more integration test (may be the same conformance test as the hyperLatentWorker does), more doc.
I have idea for developping followStartupLogs option but it's not materialized yet.