Automatic merge from submit-queue
Fix problem specifying fqdn:port in command line
When specifying --server in kubectl for example, we end up
with failure if you use "localhost:8080" instead of
"127.0.0.1:8080". This is because of the way url.Parse
works as shown in snippet:
https://play.golang.org/p/luD57S6sEz
Essentially localhost ends up as the Scheme and NOT as the Host.
So we add another check to make sure we prepend the scheme
when Host ends up being empty as well. Tested with
"kubectl --server localhost:8080 get po"
Fixes#2967
Automatic merge from submit-queue
"was not created" should be "was created"
In file pkg\client\restclient/request_test.go, line #1089, "t.Errorf("expected object was not created")" , here "was not created" should be "was created" because the if condition is "if wasCreated".
When specifying --server in kubectl for example, we end up
with failure if you use "localhost:8080" instead of
"127.0.0.1:8080". This is because of the way url.Parse
works as shown in snippet:
https://play.golang.org/p/luD57S6sEz
Essentially localhost ends up as the Scheme and NOT as the Host.
So we add another check to make sure we prepend the scheme
when Host ends up being empty as well. Tested with
"kubectl --server localhost:8080 get po"
Fixes#2967
The codec factory should support two distinct interfaces - negotiating
for a serializer with a client, vs reading or writing data to a storage
form (etcd, disk, etc). Make the EncodeForVersion and DecodeToVersion
methods only take Encoder and Decoder, and slight refactoring elsewhere.
In the storage factory, use a content type to control what serializer to
pick, and use the universal deserializer. This ensures that storage can
read JSON (which might be from older objects) while only writing
protobuf. Add exceptions for those resources that may not be able to
write to protobuf (specifically third party resources, but potentially
others in the future).
Automatic merge from submit-queue
All clients under ClientSet share one RateLimiter.
Currently we create a rate limiter for each client in client set. It makes the reasoning about rate limiting behavior much harder. This PR changes this behavior and now all clients in the set share single rate limiter. Ref. #24157
cc @lavalamp @wojtek-t
