Create endpoint for receiving a notification

[yiannistri]

The endpoint should receive webhook requests to indicate a promotion of an environment. Each environment of each pipeline has its own webhook URL for triggerring a promotion:

/pipelines/promotions/{namespace}/{name}/{environment} 

When a request is received, the handler will look up the environment in the pipeline to:

• ~authz the request~ split out to #31
• validate the promotion
• lookup and execute the promotion actions

The handler needs to run with it own set of permissions (not user permissions) to be able to read app versions across environments in a pipeline.

Having the promotion logic in the controller would allow for more fine-grained permissions and make development easier.

[enekofb]

The endpoint should receive webhook requests to indicate a promotion of an environment. Each environment of each pipeline has its own webhook URL for triggerring a promotion:

/pipelines/promotions/{namespace}/{name}/{environment} 

this is interesting in terms of semantics cause the leaf cluster is requesting a promotion but the environment actually does not know about promotions but about deployments that succeded or failed so it could makes sense to have the webhook with that semantics

as leaf cluster, i notify the management cluster that a deployment has happened for an application X with an event Y

/pipelines/deployment/{namespace}/{name}/{environment} 

or something similar ... what do you think @yiannistri ?

[enekofb]

The authz piece seems an issue in itself in the sense that

• we need to design what the is the granularity of the secret, is the application, is the cluster
• based on that, how the secret is generated
• as it is a shared secret how it is distributed so management/leaf clusters uses it

[yiannistri]

The authz piece seems an issue in itself in the sense that

* we need to design what the is the granularity of the secret, is the application, is the cluster

In my opinion, the secret should live:

• in the leaf cluster, in the same namespace as the Alert resource

• in the management cluster, in the same namespace as the Pipeline resource

  • based on that, how the secret is generated For the leaf cluster it would be the ops team that creates it. For the management cluster it could either be created by the controller or by the ops team.

  • as it is a shared secret how it is distributed so management/leaf clusters uses it I don't think we can do it without involving a human operator.

[makkes]

For the leaf cluster it would be the ops team that creates it. For the management cluster it could either be created by the controller or by the ops team.

The controller cannot maintain the Secret by itself because it needs to be the exact same one as the one on the leaf cluster. So it's either "operators create both Secrets" or "controller creates both Secrets". I'm leanings towards the ~latter~ former because we already impose the burden of creating Alert/Provider on each leaf cluster on the user, anyway.

[yiannistri]

/pipelines/promotions/{namespace}/{name}/{environment} 

this is interesting in terms of semantics cause the leaf cluster is requesting a promotion but the environment actually does not know about promotions but about deployments that succeded or failed so it could makes sense to have the webhook with that semantics

as leaf cluster, i notify the management cluster that a deployment has happened for an application X with an event Y

/pipelines/deployment/{namespace}/{name}/{environment} 

or something similar ... what do you think @yiannistri ?

@enekofb I would say that the leaf cluster is notifying the management cluster of a promotion that happened at an environment.