Skip to content

Latest commit

 

History

History
69 lines (43 loc) · 4.49 KB

0052-subscription-management.md

File metadata and controls

69 lines (43 loc) · 4.49 KB
Raw

Subscription management for Integrations

Mockup: keptn/keptn#1280

Success Criteria: Easy integration of Keptn-services into a Shipyard process.

Note: The term Keptn-service is used as a synonym to an integration that is maintained in the https://github.com/keptn-contrib organization. A Keptn-service (aka. Integration) has a subscription to an event and performs a task based on the event type and payload.

Motivation

  • Pain: After implementing KEP45, an integration is listed in the Uniform screen, and subscriptions are displayed. To change the subscription, a user needs to manually adapt the manifest of the deployed Kubernetes services (of this integration). This is not possible when no access to the Kubernetes Cluster is given.

  • Target: Allow customization of subscriptions to integrate custom Keptn-services (Integrations) into a process definition using the Bridge.

  • Driver: To foster the usage of custom integrations in Keptn, there must be UI/UX improvements in handling subscriptions of integrations.

User Cases:

As a user, I want to add multiple subscriptions to my integration by using the Bridge and then manually applying the change on a remote execution plane.

A subscription has:

  • name: Name of the subscription for display purposes
  • event: Event the subscription works on (e.g.: sh.keptn.event.deployment.triggered, sh.keptn.event.release.triggered)
  • filters: On the project, stage, and service level

image

User flow:

  • The button Add subscription opens an empty form to set name and to specify event and filters. image

As a user, I want to add multiple subscriptions to my integration by using the Bridge and then automatically apply the changes on the control-plane.

User flow:

  • See the first steps above.
  • If service is running on the control-plane, an Update subscriptions button is provided that updates the subscriptions on the cluster when clicking it. image

As a user, I want to add parameters to my subscription to enrich it with context information.

  • A subscription supports a list of parameters; a parameter is a key:value pair.

open Questions:

  • The parameters won't be added by the shipyard-controller to the .triggered event because this is custom information and Keptn core should not expose information of other subscriptions. Hence, can the distributor of the integration take care of adding the parameters to the event payload before forwarding it to the receiving service?

image

supporting Use Cases

As a user, I can validate whether my Shipyard (for this project) is covered by the uniform. If a missing subscription is found, I can add it with two clicks.

image

User flow:

  • Since the Keptn core knows the registered integrations and the Shipyard for this project, an API endpoint can derive and return the coverage of tasks (events) by subscriptions.
  • (1) The Bridge displays the Shipyard and highlights tasks that don't have a subscription.
  • The Bridge displays a drop-down containing all services that support this particular task (event). The Keptn core has to offer an endpoint, to get all registered services by their supported event type.
  • (2) - (3) By clicking the Add subscription button, an additional subscription - with the event type and stage pre-defined - is created.

As a user, I want to get notified when the deployed Keptn-service does not work with the current Keptn installation.

Next to the displayed meta-information about the Keptn-service, it should provide the info about the implemented event spec, i.e., the current Keptn event spec version: 0.2.1.

The next mockup shows three cases:

  • The implemented event spec is supported by Keptn ✔️
  • No information about the event spec version available ❌
  • The implemented event spec is not supported by this Keptn ❌

image