Subscription-Issue1: A common way to manage lifecycle of subscriptions

[shilpa-padgaonkar]

Problem description Do we need API subproject(domain) specific distinct ways of creating, updating, deleting and retrieving subscriptions? Designing the subscription lifecycle management individually in every API sub-project would lead to the subprojects reinventing the same wheel of subscription lifecycle management each time. They should instead be able to focus on domain specific events. We also need a consistent way for event consumers to subscribe to events across domains.

The subscription lifecycle management related events (SUBSCRIPTION_REQUESTED, SUBSCRIPTION_CREATED, SUBSCRIPTION_UPDATED, SUBSCRIPTION_DELETED, SUBSCRIPTION_ENDED) can also be handled in a common way. Another big change would be that domain specific information cannot be added to subscriptionDetail as is probably done today.

This issue was raised earlier in Commonalities and we decided to park (point4) for later at that time https://github.com/camaraproject/Commonalities/issues/44#issuecomment-1715855946

Possible evolution If we would agree that we need a common way of handling subscription life cycle management, there could be the following 2 options:

Subscriptions.yaml in maintained in a separate/commonalities repo and subprojects simply maintain the event types - or Subprojects create a copy of the subscriptions.yaml file (maintained in a separate/commonalities repo) from the latest release and just extend it with the domain specific sections in their subprojects

• scopes
• security schemes
• filters
• configs

Alternative solution

Additional context

149

[bigludo7]

Hello @shilpa-padgaonkar I saw 2 UC where some life cycle information should be useful:

1. Async creation - the POST is performed and the subscription is created async. If the requester making a GET what we should send back? As of today we're fine with 404.
2. Once a subscription is terminated (because expiration date in past, number of notification reached, DELETE performed) do we want to allow client side to retrieve subscription? It will probably make sense for monitoring.

Depending on our view on point 1. I will be in favor of, either:

• a very simple state engine like SUBSCRIPTION_REQUESTED (S) --> SUBSCRIPTION_ACTIVE (S) --> SUBSCRIPTION_TERMINATED (E) (by S I mean state reachable at start en E final state)
• just adding an attribute to mention that the subscription has been terminated (isExpired)

Up to my knowledge both subscription model in CloudEvent and TMF (called there hub) did not manage lifecycle.

[shilpa-padgaonkar]

Thanks for your comments @bigludo7

1. Agree on having async creation possibility.
2. Would be ok to allow client side to retrieve subscription after it is terminated and hence just add attribute when subscription is terminated.
3. Yes, as mentioned we would need to do some adaptation to the CloudEvents subscription API (if we decide to use it as a base) after we have agreed on the things we need in Camara.

One additional question:

4. Would you agree that we could have a Camara wide common subscriptions API?

[bigludo7]

Hello @shilpa-padgaonkar

Would you agree that we could have a Camara wide common subscriptions API?

We must have a common model for sure but a separate API I'm not sure. I tend to prefer to keep the subscription in each project yaml in order to have the event type listed there that seem to me more straightforward.
If we have a separate subscriptions API how we manage the type attribute within ? as a plain string or a with the enum with all possible type value?

[shilpa-padgaonkar]

@bigludo7 The types is an array of CloudEvents type values. The common subscriptions API doesn't care about all the possible type values.

IMHO, if we want to create distinct concrete subscriptions api/s (which will use the common subscriptions API as their base and then add their own type values, filters and config keys, scopes etc.) that allow grouping together multiple event types, then those event definition groups need to be at least first evaluated as I can imagine possible overlaps from different API subprojects in the future (also are our existing grouping of event definitions purely based on how subprojects are split, the right way to group event definitions?)

What we currently have (may be I missed some subprojects):

• geofencing/subscriptions (area-entered, area-left)
• device-status/subscriptions (roaming-status, roaming-on. romaing-off, country_change, connectivity-data, connectivity-sms, connectivity-disconnected)
• connectivity-insights/subscriptions (policy-met, policy-not-met)
• sim-swap/subscriptions (swapped)

Are these currently existing event definition groups & endpoints fine for us? Will this allow the event consumers to discover events in a straightforward way?

[bigludo7]

Hello @shilpa-padgaonkar

Will this allow the event consumers to discover events in a straightforward way?

This is a good question and I do not have the answer Basically we have 2 options Does a developer will look for a given function/api and here discover that there is a subscription end point and event type related to this specific API ? we have in the yaml the specific subscription endpoint for this api and associated notification type. Or Does a developer will prefer to have an aggregated view of all the notification available cross projets ? In this case we can have a generic yaml for subscription (without name of specific API in the path) and a associated document with all event type listed.

As of now our design is the first approach.

[PedroDiez]

My two cents here, think could be beneficial to have a "common template subscriptions API" (i.e. like a yaml template) with the objective for every WG it may need according to their UC and requirements to be able to re-use it and latter enhance with the specific semantics for a specific feature/track.

In this way we would achieve every WG follow the same baseline design and also accomodate common way of indicates traversal events (e.g. terminationReason events, events asociated to the lifecycle od the suscription), so every WG can focus on the specifics of the track and the particularizations required

[shilpa-padgaonkar]

Agreement to use a common template. Will be fixed with https://github.com/camaraproject/Commonalities/pull/189