Revisiting clientv3.New() connection model #6162
Comments
|
This was the root of the UT failures when enabling v3client, but it also exposed suppositions on some of the k8s tests. |
|
Great catch - thanks for letting me know. |
heyitsanthony
added a commit
to heyitsanthony/etcd
that referenced
this issue
Aug 12, 2016
heyitsanthony
added a commit
to heyitsanthony/etcd
that referenced
this issue
Aug 12, 2016
heyitsanthony
added a commit
to heyitsanthony/etcd
that referenced
this issue
Aug 12, 2016
gyuho
pushed a commit
that referenced
this issue
Aug 12, 2016
|
@smarterclayton do we have any requirements on apiserver startup behavior blocking vs. non-blocking? |
|
Right now we do polling to see if the etcd server is up before continuing, then we fail if it never responds in X seconds. |
k8s-github-robot
pushed a commit
to kubernetes/kubernetes
that referenced
this issue
Aug 19, 2016
…tests Automatic merge from submit-queue Move UTs that block on apiserver to integration tests. In validating etcd.v3client we had uncovered that a change in the behavior of the client etcd-io/etcd#6162 , caused a number of unit tests to fail. These test failures were due to the fact that the unit tests were trying to standup a apiserver even though there was no etcd backend stood up. This PR simply shuffles those tests to integration tests, which is where they should be. /cc @kubernetes/sig-scalability @wojtek-t @hongchaodeng @xiang90
perotinus
pushed a commit
to kubernetes-retired/cluster-registry
that referenced
this issue
Sep 2, 2017
…tests Automatic merge from submit-queue Move UTs that block on apiserver to integration tests. In validating etcd.v3client we had uncovered that a change in the behavior of the client etcd-io/etcd#6162 , caused a number of unit tests to fail. These test failures were due to the fact that the unit tests were trying to standup a apiserver even though there was no etcd backend stood up. This PR simply shuffles those tests to integration tests, which is where they should be. /cc @kubernetes/sig-scalability @wojtek-t @hongchaodeng @xiang90
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In v2 client New(), it just creates some http transports and connections happen when you make an api call. Hence it won't block on New().
In v3 client New(), it dials out to establish the grpc connection. It blocks and returns error if it failed to connect.
It would be ideal if we can support non-blocking clientv3.New() for some use cases.
The text was updated successfully, but these errors were encountered: