API service lifecycle operations rework

[xi-yang]

Let's expand the scope of work here. We could remove all the methods in /restapi/sense/service that only wrap around a single atomic /restapi/service or /restapi/instance method.

We will then only leave /restapi/sense/service to some composite methods that require to put several backend methods together or to handle stateful negotiation / interaction with clients. In other words, /restapi/sense/service along with /restapi/sense/discovery will serve for workflow assistance.

So for the sense/service endpoint we may only need

• initiate / negotiate (POST / or POST /{uuid}
• provision (PUT /provision/{uuid}/sync / /provision/{uuid}/async that does propagate+commit+verify)
• deprovision (PUT /deprovision/{uuid}/sync / /deprovision/{uuid}/async that does cancel+propagate+commit+verify)
• reprovision (PUT /reprovision/{uuid}/sync / /reprovision/{uuid}/async that does reinstate+propagate+commit+verify)
• modify (POST /modify/{uuid}/sync / /modify/{uuid}/async that does (modified) compile+propagate+commit+verify)

Then

• All other methods will be on existing profile, instance, intent and logging endpoints.
• We will keep all the existing /sense/service calls for backward compatibility for at least by R21.

---

Original:

This is to track a group of 2* sub tasks in #1.

For now, we will add Reinstate and Modify calls.

• [x] 2d. + Reinstate op with intent UUID

• [x] 2e. + Modify op with new intent data (full)

We will evaluate whether encapsulate force_cancel and force_retry here or provide their original form under /instance. For easy security policy that only expose /restapi/sense to users, the latter might be a better approach.

• ?? force_cancel
• ?? force_retry

[xi-yang]

@R-Jimenez For the above plan, can we go through the endpoints to have a full check on the authorization enforcement in keeping a user from accessing resources outside of its entitled service instance scope.

[R-Jimenez]

Very interesting, but shouldn't be too big an issue straightening things out.

Can you clarify the above addendum? I presume you're talking about our earlier conversation about operations and delegation trickiness. What exactly is the entitled service instance scope?

[R-Jimenez]

After our first wave of work on the API, we've established API-level authorization and access controls. The only other major resource to strip and refactor would be the DataResource, which is supposed to serve only as a packaging middleman for the portal, but has grown a bit unruly and out of scope. As this wouldn't really affect the CLI or user experience, it's fine for us to put this off for the moment for other concerns and developments.