-
Notifications
You must be signed in to change notification settings - Fork 385
Rebase on 1.7 API machinery #944
Rebase on 1.7 API machinery #944
Conversation
One of the major things broken after migrating to the latest IIRC the insecure server was used at least for the walkthrough and integration tests. |
looks like I managed to fix most of the issues with API server and Admission control, and Service Catalog compiles now, but the tests are still failing |
The examples for the changes were mostly taken from https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/sample-apiserver (and some others are based on the history of commits for the particular types) |
@@ -141,6 +141,9 @@ func TestCreateWithNoNamespace(t *testing.T) { | |||
Spec: sc.BrokerSpec{ | |||
URL: "http://my-awesome-broker.io", | |||
}, | |||
Status: sc.BrokerStatus{ | |||
Conditions: []sc.BrokerCondition{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems there was some change which affected treating nil
arrays in JSON encoding/decoding.
Without this change (and other changes in this file), deepCompare
fails with error:
input and output are different:
object.Status.Conditions:
a: []servicecatalog.BrokerCondition(nil)
b: []servicecatalog.BrokerCondition{}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change you're referring to is using protobuf serialization in etcd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replacing reflect.DeepEqual with semantic.DeepEqual worked
@@ -31,16 +31,16 @@ type ServiceCatalogServerOptions struct { | |||
StorageTypeString string | |||
// the runtime configuration of our server | |||
GenericServerRunOptions *genericserveroptions.ServerRunOptions | |||
// the admission options | |||
AdmissionOptions *genericserveroptions.AdmissionOptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AdmissionOptions were moved out of genericserveroptions.ServerRunOptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the apimachinery repo, you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pmorie Yes, now they need to be explicitly declared separately from ServerRunOptions
// the https configuration. certs, etc | ||
SecureServingOptions *genericserveroptions.SecureServingOptions | ||
// authn for the API | ||
AuthenticationOptions *genericserveroptions.DelegatingAuthenticationOptions | ||
// authz for the API | ||
AuthorizationOptions *genericserveroptions.DelegatingAuthorizationOptions | ||
// InsecureOptions are options for serving insecurely. | ||
InsecureServingOptions *genericserveroptions.ServingOptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Insecure (HTTP) server is not supported anymore, only HTTPS is supported by API server now
|
||
// registerAllAdmissionPlugins registers all admission plugins | ||
func registerAllAdmissionPlugins(plugins *admission.Plugins) { | ||
lifecycle.Register(plugins) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Admission plugins registration is not global anymore, requires *admission.Plugins
instance
Unit tests succeed now, but integration tests fail because of removed insecure (HTTP) server support:
Need to refactor all the places where we depend on insecure server:
|
While I applaud the initiative taken here, as you can tell, it's a very large change and has a lot of implications. So, before we merge this change, we really need to:
The protobuf serialization and losing support for insecure are the two pieces that worry me the most. In the interest of full disclosure, our last rebase onto newer machinery took a couple weeks to land. I think you should expect that there will be a similar time-frame for this one. |
@pmorie Fair enough, let's see how it goes after Kubernetes 1.7 is released |
I wanted to do something like this as well, but only to move from 1.6-rc1 to 1.6.4. I think we need to write down a policy & process for what we want to do. I'm someone surprised the integration tests are breaking. They used to all be https enabled, but I guess the insecure server snuck in somehow. |
@MHBauer that was just my guess, could be some other issue with secure server then |
admission.RegisterPlugin(PluginName, func(io.Reader) (admission.Interface, error) { | ||
// Register registers a plugin | ||
func Register(plugins *admission.Plugins) { | ||
plugins.Register(PluginName, func(io.Reader) (admission.Interface, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yay, we'll get rid of an init. This was being done upstream and we're following? If so, that's very good and makes me happy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I can help with the secure/insecure server stuff. I'm not sure if we want to do it now or right around 1.7. I see there were some concerns about timeouts or something which prompted the move to insecure. I wish the servers took a 0 port to mean "bind me something unbound" like every other server instead of overloading a port number to mean "I don't want a server". |
Further the check shouldn't be using http to see if the apiserver is up, as the actual test uses https. |
@MHBauer Your help would be greatly appreciated. I don't think we have to wait until 1.7 is released to continue working on this pull request, as 1.7-rc.1 is out already and there should be no API changes breaking our code (it would be nice to update the dependency in |
I was wrong. There was a hidden manual override in the kubectl script so it always used http. Can try and see if #991 makes it get farther in the tests. Doesn't solve the golang integration tests. Only the kubectl<->apiserver communications. |
I will rebase this PR once kubernetes/client-go#231 is addressed. |
Rebased. Integration tests fail for some reason. I'm sorry, don't have time to debug them at the moment. At least everything seem to compile. I used apiserver hash that is from 23rd of June - same day last client-go/apimachinery resync for 1.7 happened. Filled kubernetes/apiserver#16 to get proper version. |
@ash2k it's the same failure as before re-rebasing (see it mentioned above):
I believe it's failing due to waiting for insecure server to start up, which is not available anymore. |
After applying the fix #1015 I get:
TLS handshake fails for some reason.
|
Yes, I can still help. I want this done. Do we have an acceptable and known compile compatible levels of all the libraries picked out? I'll take a look at the tests in the morning. |
pkg/apiserver/config.go
Outdated
Codecs = serializer.NewCodecFactory(Scheme) | ||
) | ||
|
||
func init() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this truly necessary? My hate for inits knows no bounds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ask @deads2k :) https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/sample-apiserver/pkg/apiserver/apiserver.go#L44
I don't remember why I copied this, presumably something didn't work without that but I'll double check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this method invokes apimachinery AddToGroupVersion
(https://github.com/kubernetes/apimachinery/blob/master/pkg/apis/meta/v1/register.go#L43) which should register the ExportOptions
type, so I'm not sure why I see the error in the log mentioned above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this code to a separate file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a constant/global for the binary. Not having an init block just means that you can have a uninitialized value that creates unusual behavior until you wrap a method in a sync.Once and then have every caller to your package call it. That's nuts.
Alternatively, you could plumb it as an arg everywhere that needs it, which is a valid solution, but a level of purity we hadn't reached in the apiserver refactors yet.
@MHBauer @ash2k see my latest commit. I managed to start a server, the integration test build is failing now:
Happy to look at it later. |
Now the server starts up, but there is a TLS handshake error in test/integration/framework.go#L105:
We probably need some client-side configuration for accepting the self-signed certificate. |
for the 'check if it's up yet' part in
|
This should help with the svc-cat client configuration.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great; a couple small asks and comments below. I have not yet had a chance to pull this branch and test it out; that is one of my priorities tomorrow morning.
Welcome to the small club of those who have rebased on the k8s API machinery. The question I ask everyone who has done this is: what did you have to explore in the machinery to understand the necessary changes? Can any comments be improved in the API machinery? If any fixes came immediately to mind, it would be fantastic to get PRs for them into k8s if you have some time, and issues at least, if you don't.
A couple observations I made:
- The actual commit for the code changes aside from bumps and regen is really small -- 238 total diff stat lines (!)
- Things seem to be moving in the right direction in terms of removing global registrations (example: admission controller plugins)
- Dependency bump is pretty enormous :)
cmd/apiserver/app/server/util.go
Outdated
// server configuration options | ||
if err := s.SecureServingOptions.MaybeDefaultWithSelfSignedCerts(s.GenericServerRunOptions.AdvertiseAddress.String()); err != nil { | ||
if err := s.SecureServingOptions.MaybeDefaultWithSelfSignedCerts(s.GenericServerRunOptions.AdvertiseAddress.String(), nil, []net.IP{net.ParseIP("127.0.0.1")}); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can you doc the nil param here with a /* ... */
inline comment? Helps to make nil parameters much more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -143,6 +143,8 @@ func Run(controllerManagerOptions *options.ControllerManagerServer) error { | |||
// TODO: disambiguate API errors | |||
return fmt.Errorf("failed to get Service Catalog client configuration: %v", err) | |||
} | |||
// TODO (nilebox): Dirty temporary hack. Should whether accept as flag for application, or handle TLS correctly | |||
serviceCatalogKubeconfig.Insecure = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be fine running a flag for TLS verification to the SC API server in this PR; should be a fairly simple change.
@@ -156,7 +157,7 @@ func roundTrip(t *testing.T, codec runtime.Codec, item runtime.Object) { | |||
return | |||
} | |||
|
|||
if !api.Semantic.DeepEqual(original, item) { | |||
if !equality.Semantic.DeepEqual(original, item) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the package change here is due to the new version of demantic dep equal that isn't broken by protobuf changes, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct
pkg/apiserver/util.go
Outdated
@@ -56,7 +56,7 @@ func createSkeletonServer(genericCfg *genericapiserver.Config) (*ServiceCatalogA | |||
// only way to get here from there is by Complete()'ing. Thus | |||
// we skip the complete on the underlying config and go | |||
// straight to running it's New() method. | |||
genericServer, err := genericCfg.SkipComplete().New() | |||
genericServer, err := genericCfg.SkipComplete().New("service-catalog-apiserver", genericapiserver.EmptyDelegate) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this a const?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -94,12 +94,12 @@ func toSelectableFields(binding *servicecatalog.Binding) fields.Set { | |||
} | |||
|
|||
// GetAttrs returns labels and fields of a given object for filtering purposes. | |||
func GetAttrs(obj runtime.Object) (labels.Set, fields.Set, error) { | |||
func GetAttrs(obj runtime.Object) (labels.Set, fields.Set, bool, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will you godoc the parameters or use names? It's hard to infer what the bool represents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pmorie GetAttrs is not documented upstream. I do not expect anyone to know what these args are. @cheftako
https://github.com/kubernetes/apiserver/blob/master/pkg/storage/selection_predicate.go#L25-L27
// AttrFunc returns label and field sets and the uninitialized flag for List or Watch to match.
// In any failure to parse given object, it returns error.
type AttrFunc func(obj runtime.Object) (labels.Set, fields.Set, bool, error)
https://github.com/kubernetes/apiserver/blob/master/pkg/storage/selection_predicate.go#L25-L27
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking through git history the bool is "the uninitialized flag". I do not know what that means. My guess from looking at the commit is whether the thing that we're getting has been set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pmorie as @MHBauer pointed, the change just follows the breaking change in AttrFunc
method https://github.com/kubernetes/apiserver/blob/master/pkg/storage/selection_predicate.go#L25
And the method doesn't have any parameters description in many implementations: podtemplate/strategy.go#L92, replicationcontroller/strategy.go#L148, daemonset/strategy.go#L134.
I agree that it is not well documented, but for Service Catalog just being compliant with Kubernetes core code should be enough. It makes it easier to sync up all the breaking changes as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking through git history the bool is "the uninitialized flag".
@MHBauer it is the "uninitialized flag", as mentioned in the comment to the AttrFunc you quoted above. I would prefer to keep it as it is to be in sync with upstream.
I do not know what that means. My guess from looking at the commit is whether the thing that we're getting has been set?
it checks whether there is still at least one initializer set (see comment to the field meta/v1/types.go#L216):
// This field is a list of initializers that have not yet acted on this object. If nil or empty,
// this object has been completely initialized. Otherwise, the object is considered uninitialized
// and is hidden (in list/watch and get calls) from clients that haven't explicitly asked to
// observe uninitialized objects.
if there is at least one initializer set, it means that object is not fully initialized yet. Or, in other words, it is "uninitialized". The uninitialized objects are ignored for list/watch requests by default, as the comment above describes - that's what "unitialized flag" is for.
"initializers" approach seem to be similar to "finalizers" (but for the opposite purpose), if that helps to understand the mechanics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nilebox thanks for the explanation. I think you could get a nice PR upstream with some of this as documentation.
@@ -94,12 +94,12 @@ func toSelectableFields(broker *servicecatalog.Broker) fields.Set { | |||
} | |||
|
|||
// GetAttrs returns labels and fields of a given object for filtering purposes. | |||
func GetAttrs(obj runtime.Object) (labels.Set, fields.Set, error) { | |||
func GetAttrs(obj runtime.Object) (labels.Set, fields.Set, bool, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing on the other GetAttrs
funcs
"github.com/kubernetes-incubator/service-catalog/pkg/apis/servicecatalog/install" | ||
) | ||
|
||
var ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cheftako This new file would have been a good thing to explain in API machinery release notes.
@@ -54,6 +54,13 @@ type ControllerManagerConfiguration struct { | |||
// ServiceCatalogKubeconfigPath is the path to the kubeconfig file with | |||
// information about the service catalog API server. | |||
ServiceCatalogKubeconfigPath string | |||
// InsecureSkipVerify controls whether a client verifies the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment was shamelessly stolen from crypto/tls
@@ -54,6 +54,7 @@ spec: | |||
- --service-catalog-api-server-url | |||
- https://{{ template "fullname" . }}-apiserver | |||
{{- end }} | |||
- "--service-catalog-insecure-skip-verify=true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why on by default? I feel like that should be mentioned in the readme/walkthrough somewhere. I'd prefer if we could have everything be secure by default. And if not, I'd like to fully understand why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be wrong, but if we want to disable this flag, we also need to pass some extra information in the controller-manager (information about cerificate and authority we trust to). Without it the TLS verification will still fail.
In other words, this flag doesn't fix the original problem, just removes the hack from the code.
I haven't fully analyzed the part of interaction between controller-manager and service-catalog, and would prefer to ask someone more familiar with it (you? 😉) to test it with disabled flag and raise a separate PR adressing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with looking at it separately.
Rebase makes me sad. I still want this. A lot. |
@MHBauer I'll rebase once I get one more LGTM |
sigh... I have some issue with
@MHBauer can you try if it works for you? |
holy crap, we segfaulted git? First, rewinding head to replay your work on top of it...
Applying: Update vendor
Using index info to reconstruct a base tree...
M glide.lock
M glide.yaml
.git/rebase-apply/patch:4608: trailing whitespace.
"details": [{"code": "conflict1", "message":"error message1"},
.git/rebase-apply/patch:5806: trailing whitespace.
.git/rebase-apply/patch:5863: trailing whitespace.
2015/11/08 18:28:39 loading certificate...
.git/rebase-apply/patch:5864: trailing whitespace.
2015/11/08 18:28:39 retrieve oauth token...
.git/rebase-apply/patch:5865: trailing whitespace.
2015/11/08 18:28:39 querying the list of resource groups...
/usr/local/Cellar/git/2.13.0/libexec/git-core/git-rebase--am: line 16: 80355 Segmentation fault: 11 git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" ${gpg_sign_opt:+"$gpg_sign_opt"} < "$GIT_DIR/rebased-patches" I've never seen messages like this. Tried optimizing the git repo. use a different strategy finally worked. Give that glide.lock is one of the files, it's probably better to regenerate the first two commits manually and then cherry pick the second two of the set. |
I see
Which is all generated code... |
@MHBauer pushed updated vendor and auto-generated files.
|
Fixed Still have some failure in integration test:
Tried to manually deploy Service Catalog to minikube to test it, have some issue with RBAC:
It worked for me before:
Looks like whether RBAC PR broke something, or I am missing something. |
looks like the healthchecker test is failing. maybe because no insecure? I will continue to debug.
|
lawlz, it's the exact same solution as the other thing, at least for the test.
|
… and temporarily disable TLS verification on client side
Disable TLS verification for healthcheck client
@MHBauer Thanks, added fix for healthcheck integration test (disabled TLS verification). |
@@ -143,6 +143,8 @@ func Run(controllerManagerOptions *options.ControllerManagerServer) error { | |||
// TODO: disambiguate API errors | |||
return fmt.Errorf("failed to get Service Catalog client configuration: %v", err) | |||
} | |||
// TODO (nilebox): Dirty temporary hack. Should whether accept as flag for application, or handle TLS correctly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/whether/we/ ?? not sure what its trying to say
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"accept as --skip-verify flag" (instead of hardcode) OR "handle TLS correctly" (by passing certificate authority and other stuff into client configuration). sorry for my poor English if it's confusing you.
This comment is obsolete anyway, I went with the flag for now (see newer commits), as suggested by @pmorie.
We will still need to fix all the places where we pass --insecure-skip-verify
flags by adding TLS configuration on the client side, but I see this to be a separate PR, and I think we have agreement on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the comment is obsolete should we remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok thanks
Everything appears as it should be after some quick tests this morning. Still LGTM. |
LGTM |
There was a bug in Kubernetes I found (kubernetes/kubernetes#46817) and fixed (kubernetes/kubernetes#46683) recently and I want one of the projects I'm working on (Smith) to pick it up. So I need to update dependency on apimachinery repo. Smith integrates with Service Catalog and hence I need to satisfy the Service Catalog dependency as well. Currently if I just update client-go and apimachinery to the latest versions some stuff from Service Catalog that I use in Smith will not compile. Hence the attempt to update the dependencies.
There are some places that still do not compile but I don't know how to fix them :(
/cc @arschles