Request to restrict OldRelease and NewRelease instances while fetching for http-c of application

[IswaryaaS]

Problem Description :

When a new release of existing application is entering into the architecture, it will update the http-c , tcp-c of Old Release in config file with the preceding application information provided in request body of /v1/register-yourself.

Once the application is approved and receives “embed-yourself” , a callback will be triggered to the old application’s “/v1/bequeath-your-data-and-die” .

When /v1/bequeath-your-data-and-die is executed, as part of callback PromptForBequeathingDataCausesRequestForBroadcastingInfoAboutServerReplacement , the new application also shall receive /v1/update-client from RO.

As part of execution of /v1/update-client , it will find whether applications exists or not , if it exists it will update the instance with given details .

• During this stage, the request-body will contain current-application-name and current-release-number attributes as same as OldRelease of this application. Because of this, it is considering OldRelease client instance instead of correct instance.
• Thus, operation-clients gets transferred from OldRelease instance to http-c instance with future-application-name and future-release-number combination.

Proposal :

In OAS , for services like /v1/update-client, /v1/update-operation-client can we add description for application-name and release-number attributes like
" **update shall be made considering http-c instances excluding OldRelease and NewRelease http-c instances** " .

Note : In implementation, the OldRelease and NewRelease instances shall be considered from forwarding-constructs like PromptForEmbeddingCausesRequestForBequeathingData and PromptForBequeathingDataCausesTransferOfListOfApplications respectively. (The forwardings would vary based on application)

[openBackhaul]

Change to be made at the OAS:
In

• /v1/update-client and
• /v1/update-operation-client

the description has to be changed towards "update shall be made excluding OldRelease and NewRelease http-c instances" at application-name and release-number attributes .

[IswaryaaS]

Apart from /v1/update-client and /v1/update-operation-client services, this change would also be required for

• /v1/redirect-service-request-information,
• /v1/redirect-oam-request-information,
• /v1/inquire-oam-request-approvals and
• /v1/redirect-topology-change-information

[openBackhaul]

@IswaryaaS please double check and comment:
.
.
/v1/update-client and /v1/update-operation-client are searching through all LTPs

find [/core-model-1-4:control-construct/logical-termination-point=*-1-0-0-http-c-*/layer-....

(regard ...=*-1-0-0-http-c-* ...)
and it makes sense to exclude OldRelease and NewRelease from this search

find, but not at OldRelease or NewRelease, [/core-model-1-4:control-construct/logical-termination-point=*-1-0-0-http-c-*/layer-....

.
.
/v1/redirect-service-request-information, /v1/redirect-oam-request-information, /v1/inquire-oam-request-approvals and /v1/redirect-topology-change-information are addressing concrete LTPs, a.g.

find [/core-model-1-4:control-construct/logical-termination-point=*-1-0-0-http-c-eatl-2-0-1-000

(regard ...=*-1-0-0-http-c-eatl-2-0-1-000 ...)
and it does not seem to make sense to exclude OldRelease and NewRelease from this "search", right?

[IswaryaaS]

Hi @openBackhaul , You are right.

But, since we follow the practice of not hardcoding the uuid into the code, we use the attributes "application-name and release-number" for selecting the expected instance. In few cases, when OldRelease or NewRelease instances are updated with real-time values, this clash happens.

For example,

If we exclude OldRelease and NewRelease (which would be found through forwardings in implementation), we can eliminate this ambiguity.

Note: the above scenario is specific to ExecutionAndTraceLog for service /v1/redirect-service-request-information.
Similarly, /v1/inquire-oam-request-approval is specific to AdministratorAdministration, /v1/redirect-oam-request-approval to OamLog and /v1/redirect-topology-change-information to ApplicationLayerTopology

Kindly let me know your views.

[openBackhaul]

Added change to /v1/redirect-service-request-information, /v1/redirect-oam-request-information, /v1/inquire-oam-request-approvals and /v1/redirect-topology-change-information.