Extended scenario: multiple-client use of deployed resource

This is an extension of the Temporary deployment scenarios.

Once the resource has been deployed then other Clients, or other users or resources on the same Client, could notify the Provider that they are using (or have a “using interest”) in that deployed resource, and the Provider will only tear it down after they have all finished using it. The initial Client who requested the deployment could include a property on the request, which should be mirrored on the result, whether they intend the deployment for single-Client use or for shared use.

• Client 1 creates a request, and either:
  • Client 1 indicated that it was sharable, or
  • Client 1 did not indicate a sharing preference and the Provider’s default is to allow sharing
• The Provider does the deployment
• Client 2 sees the result, and that it has been deployed and not torn down, and that it is sharable, and that it wants to use it
• Client 2 informs the Provider that it is using that result (registers itself as an interested party)
• Client 1 finishes with the deployed resource and notifies the provider of this
• The Provider does NOT tear down the deployed resource
• Client 2 finishes with the deployed resource and notifies the provider of this (deregisters itself as an interested party)
• The Provider tears down the deployed resource (immediately or at a later time)

Effect on standardisation options

Effect on option Temporary deployment: “Teardown plan” property on Automation Result

Pros:

• If there are multiple clients who have registered an interest in this result, then for all except the last client the linked “undeploy” autoPlan merely removes them from the interested parties list.

Effect on options Temporary deployment: Automation Result state

• There’s a minor issue that once Client 1 indicates that they are finished by setting the desiredState to “torn down” (or whatever the final state is) it will sit in that state until all the interested parties have deregistered. (See point 2 in the “Extended option” below). However, maybe that is an appropriate way of showing that the deployed resource is in a state of “will be torn down when all interested parties deregister”.

Mechanism for registering interest

• A partial update (see PATCH) on automation result to add a URL representing itself to a collection of “interestedParties”. That URL is arbitrary from the Provider’s point of view, but must be under the control of the Client (i.e. under the client’s domain name) in such a way that it is unique across clients. For clients who are not accessed themselves via a URL, they could use their IP address on their local network with a UUID appended, e.g. http://10.0.0.1/f81d4fae-7dec-11d0-a765-00a0c91e6bf6 (although it would be better if this were not an http URI, but something like the tag: scheme or urn: instead).

• If the client sends an initial request without specifying whether or not it is sharable, the Provider default is used. I would suggest the default should be to allow it to be sharable for most cases (but some providers may have specific cases).

Extended option

This is an extended version of Temporary deployment: Automation Result state

When shutting down:

1. Client 1 sets the desiredState property to the final state (e.g. “torn down”)
2. If it receives a 2xx return code, then it should consider its request accepted. Only if it really wants to wait until the teardown is finished should it poll the actual state, otherwise it should just consider the deployed resource gone.
3. The Provider keeps the result in the state that indicates it is deployed and not torn down, and keeps the desiredState as the state set by Client 1.
4. Client 2 removes itself as an interested party
5. The Provider sees that it has a deployedState indicating that tear down is requested, and there are no interested parties registers, so tears down the deployed resource.

Note that the clients act differently depending on whether they were the client who created the request, or a client who discovered an existing result to use. This is a benefit as it allows the “interested parties” behaviour to be optional on the client-side. Clients who do not implement that behaviour can still create requests, and can still request them to be torn down when they have finished with them. However, they must understand that they ought to check the response code of the PUT they used to set the desired state rather than polling to wait for the actual state to change.

We suggest the extended option.

Issues

• Should the initial requesting client (or any other client) be able to force a shutdown irrespective of the interested parties list?
  • They could probably do this by clearing the interested parties list themselves, then tearing down as usual. Therefore we should allow any client to remove any entry in this list, or alternatively provide a “force tear down” option somehow.
• Note that other clients (e.g. orchestrators, managers) who may want to tear the deployed resource down will be subject to the same constraints as the initial requesting client. That is, it will not be shut down until the interested parties list is empty.
• Dealing with clients that register as an interested party (or create a request) then never deregister themselves (e.g. crash or hang).
  • Perhaps have a timeout? Clients could provide their own timeout (up to a Provider-specified maximum) or the Provider could have a default. Clients could increase their timeout periodically if they are still using it, allowing them in total to go beyond the Provider-specified maximum.
• The term “interested party” might be too vague, because it is specifically clients that are using the deployed resuorce, not all who have an interest in it (e.g. there might be some who are interested in being notified when it is torn down, but are not actively using it). Perhaps “inUseBy” is a better name for the relationship.
• Consumer registration of interest mechanism. Proposals include:
  • A new resource created by consumers (TODO: poll other workgroups for common/similar need)
  • Consumer updates automation result
  • A compromise, where consumers update the automation result (as in the 2nd proposal) with a URI that may or may not be a link to the new consumer-resource (as in the 1st proposal). We could say that providers MAY enforce a restriction on the range of the property in the automation result such that it must point to a consumer-resource, if the provider requires other properties on that resource.
  • Others?