Skip to content

APIGOV-33010 provisioning webhook dispatch - #1097

Open
alrosca wants to merge 8 commits into
mainfrom
APIGOV-33010
Open

APIGOV-33010 provisioning webhook dispatch#1097
alrosca wants to merge 8 commits into
mainfrom
APIGOV-33010

Conversation

@alrosca

@alrosca alrosca commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

No description provided.

@alrosca
alrosca marked this pull request as ready for review September 8, 2026 12:56
}
if action == proto.Event_SUBRESOURCEUPDATED && event.Metadata.GetSubresource() == defs.XWebhookDetails {
return true
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Just a thought here, would like more opinions....

Considering we now can have handlers for the same type with different subresouces if event types specified, do we want to consider moving new actions like this to their own handler?

Another thought. Since the pattern is pretty equal, could all webhook subres handling be in the same handler amongst the provisioning resrouces?

Finally, should this check also validate that the webhook config is actually set on the handler?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Depending on the responsibilities we want the webhook to handle, a new handler for each resource might be necessary. Otherwise, a separate handler for the webhook subresource only might be a good idea

func WithAccessRequestProvisioningWebhook(cfg config.ProvisioningWebhookEndpointConfig, client api.Client) func(c *accessRequestHandler) {
return func(c *accessRequestHandler) {
c.webhookCfg = cfg
c.webhookClient = client

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Is this client a separate client from the one that is added to the handler already? Could the client already on the handler be updated to support both?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I would not extend the handler client with webhook dispatch functionality because of the different purposes these two client have

Comment thread pkg/agent/handler/accessrequest.go Outdated
func (h *accessRequestHandler) onPending(ctx context.Context, ar *management.AccessRequest, mar *apiv1.ResourceInstance) *management.AccessRequest {
log := getLoggerFromContext(ctx)

if h.webhookCfg != nil && h.webhookCfg.IsConfigured() && webhookDispatchedFor(ar, webhookOperationProvision) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

does it makes sense to use a default webhook config on the handler that would result in IsConfigured returning false instead of having to check nil?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants