Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

⚠️ split webhook server and manifest generation #300

Merged
merged 2 commits into from
Feb 14, 2019

Conversation

mengqiy
Copy link
Member

@mengqiy mengqiy commented Jan 17, 2019

Code related to running a webhook server stays in CR repo.
Code related to generating cert are dropped.
Code related to generating non-cert manifests (e.g. webhookConfiguration, service) are currently under pkg/webhookgenerator,which will be moved to the controller-tools repo.

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Jan 17, 2019
@k8s-ci-robot k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jan 17, 2019
@mengqiy
Copy link
Member Author

mengqiy commented Jan 17, 2019

The PR is not polished yet.
Sent out the draft for getting feedback before @DirectXMan12 disappears next week :)

@mengqiy mengqiy force-pushed the decouple branch 2 times, most recently from 8f03a29 to 4589fd6 Compare January 17, 2019 22:08
Copy link
Contributor

@droot droot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a quick look and have a few questions.

"sigs.k8s.io/controller-runtime/pkg/internal/webhookgenerator/types"
)

// Webhook represents each individual webhook.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be we can describe it a bit more:

Webhook contains bits needed for generating a Webhook Configuration/manifest ? 

)

// ServerOptions are options for configuring an admission webhook server.
type ServerOptions struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may be we should rename the filename to be also server_options.go ?

// store it in this directory.
// If using SecretCertWriter in Provisioner, the server will provision the certificate in a secret,
// the user is responsible to mount the secret to the this location for the server to consume.
CertDir string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think most of these comments need to be re-written from the new purely generation perspective. Currently they read as if webhook server itself is going to use these options to install webhook configuration.

s.setDefault()

return s.InstallWebhookManifests()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above. Some of these methods Register and Start doesn't seem relevant from purely generation perspective.

@mengqiy mengqiy force-pushed the decouple branch 3 times, most recently from 03c3f1b to b2ea9dc Compare February 4, 2019 23:58
@mengqiy mengqiy changed the title [WIP] split webhook server and manifest generation split webhook server and manifest generation Feb 4, 2019
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 4, 2019
@mengqiy mengqiy removed the request for review from pwittrock February 5, 2019 00:08
@mengqiy mengqiy added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 5, 2019
@mengqiy mengqiy changed the title split webhook server and manifest generation ⚠️ split webhook server and manifest generation Feb 6, 2019
@mengqiy mengqiy force-pushed the decouple branch 4 times, most recently from fda3ed5 to 2ddd02d Compare February 7, 2019 01:35
@mengqiy
Copy link
Member Author

mengqiy commented Feb 7, 2019

PTAL

@mengqiy
Copy link
Member Author

mengqiy commented Feb 12, 2019

Pushed a little more changes on top of the earlier commit.
The 2nd commit is intended to be squashed into the 1st one.

Copy link
Contributor

@DirectXMan12 DirectXMan12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comments inline

ServerOptions: options,
manager: mgr,
}

return as, nil
}

// setDefault does defaulting for the Server.
func (s *Server) setDefault() {
if len(s.Name) == 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove this name field (I've removed it in #323 IIRC, so we can just wait till that if you want)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup.
It was for the name (identifier) of each individual webhook, but it is no longer used anywhere in CR.

s.registry = map[string]http.Handler{}
}
if s.sMux == nil {
s.sMux = http.DefaultServeMux
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is the default mux different from the mux used if you call the constructor?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for that matter, why do we have a constructor if we've got the setDefaults style?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is the default mux different from the mux used if you call the constructor?

Thanks for catching this.
I agree we should use the same mux. i.e. use http.NewServeMux().

for that matter, why do we have a constructor if we've got the setDefaults style?

Because some users may use the public Server struct directly, we need to ensure it get sane defaulting and works.

s.CertDir = path.Join("k8s-webhook-server", "cert")
}

if s.Client == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we shouldn't be auto-initializing the client like this. We don't actually use this anywhere, so we shouldn't have a client field at all

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized it too when fixing the injector for webhook. I have dropped it in #316.


// manager is the manager that this webhook server will be registered.
manager manager.Manager

// httpServer is the actual server that serves the traffic.
httpServer *http.Server
// err will be non-nil if there is an error occur during initialization.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this design is weird. We can leave this in for now, but I don't think it makes much sense to leave in long-term

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(e.g. multiple registrations will overwrite errors)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is kind of the same pattern as kubectl resource builder.

e.g. multiple registrations will overwrite errors

You are right. We can probably make it an array of errors i.e. []error.

If you really don't like it, we rethink how to handle it :)

return err
for path := range s.registry {
// TODO(mengqiy): remove this in PR #316
if wh, ok := s.registry[path].(Webhook); ok {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this inject code isn't quite right the way it's written, since someone could write their own webhook impl that needed the info. If webhook isn't an interface, this isn't a problem.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixed in a4ef929#diff-fbc18bb07cdd05391b7081acc1dfe170R209
I tried to avoid putting everything in the same PR, so the code here may look incorrect.

@mengqiy
Copy link
Member Author

mengqiy commented Feb 13, 2019

PTAL

ClientConfig: cc,
Objects: s.webhookConfigurations,
})
listener, err := tls.Listen("tcp", net.JoinHostPort("", strconv.Itoa(int(s.Port))), cfg)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yay! JoinHostPort 👍

Copy link
Contributor

@DirectXMan12 DirectXMan12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 14, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12, mengqiy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 14, 2019
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 14, 2019
@k8s-ci-robot
Copy link
Contributor

New changes are detected. LGTM label has been removed.

@mengqiy
Copy link
Member Author

mengqiy commented Feb 14, 2019

Squashed the commits, no new code change.
Re-applying the lgtm label per #300 (review)

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 14, 2019
@mengqiy mengqiy added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 14, 2019
@k8s-ci-robot k8s-ci-robot merged commit c2f9dae into kubernetes-sigs:master Feb 14, 2019
@mengqiy mengqiy deleted the decouple branch February 15, 2019 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants