openbackhaul / applicationlayertopology Goto Github PK

Decision on the Application Implementation call on 13th or May:
The detailed-logging-is-on attribute shall be added to the response body of the /core-model-1-4:control-construct path in the OAS.
It shall be added to the properties section, but not the required section.

All applications do no longer request for old-operation-key attribute during update of operation keys by OKM (see ApplicationPattern/issues/21 ).
Thus, OKM does no longer require ALT://v1/provide-current-operation-key.

/v1/provide-current-operation-key to be deleted from ALT.

Error description:
In callback "PromptForBequeathingDataCausesRObeingRequestedToNotifyApprovalsOfNewApplicationsToNewRelease" and "PromptForBequeathingDataCausesRObeingRequestedToNotifyWithdrawnApprovalsToNewRelease", we have request-body attribute "subscriber-operation", the reference path under description of the attribute needs an update. The path is intended to refer an operation-server ltp (alt-0-0-1-op-s-3001 and alt-0-0-1-op-s-3002), but the proceeding path points to operation-client.

Possible solution:
In the description, path needs an update to point to operation-server-interface-capability/operation-name as below.

For PromptForBequeathingDataCausesRObeingRequestedToNotifyApprovalsOfNewApplicationsToNewRelease, the current description contains /core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-op-s-3001/layer-protocol=0/operation-client-interface-1-0:operation-client-interface-pac/operation-client-interface-configuration/operation-name, which actually would be
/core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-op-s-3001/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name

For PromptForBequeathingDataCausesRObeingRequestedToNotifyWithdrawnApprovalsToNewRelease, the current description would be updated as
/core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-op-s-3002/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name

Note: alt-0-0-1-op-s-3001 refers to /v1/regard-application and alt-0-0-1-op-s-3002 refers to /v1/disregard-application

Related issues:
openBackhaul/RegistryOffice#91
openBackhaul/TypeApprovalRegister#40
openBackhaul/ExecutionAndTraceLog#41
openBackhaul/OamLog#38
openBackhaul/AdministratorAdministration#37
openBackhaul/OperationKeyManagement#28

We have the service /v1/redirect-topology-change-information, which the ApplicationLayerTopology application subscribes another application in the MS environment for getting notified for changes in the LTP or FC of the application. In this case , the application being subscribed is the same application (ALT) which forces the changes happening in LTP and FC to change again in the ALT itself. This seems to be a process that finally has no effect on the data-file structure.

I could see that since it is a basic service, we are having it in ALT as well, but my concern is, since ALT has been subscribed to all other applications in ALT which will result in very frequent changes in it's own LTP and FC due to changes in other application's load file, which in turn will result in many follow up callbacks (as we have 11 callbacks for the request) due to change in its own LTP and FC, which night not have any extra effect in the load-file. Please let me know if there is any specific reason on having the service request.

Note : Similar to issue 4

Describe your feature request :

Support functionality and forwarding for the service /v1/list-operation-clients-reacting-on-operation-server

Implementation tasks and next steps :

• Complement the listOperationClientsReactingOnOperationServer operation in controller/IndividualServices.js
• Complement the listOperationClientsReactingOnOperationServer operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

Decision on the Application Implementation call on 13th or May:
minLength:6 to be added to all operation-name attributes in the ingress bodies.

ExecutionAndTraceService has been moved from package onf-core-model-ap-bs to onf-core-model-ap in PR openBackhaul/ApplicationPattern#141

Please, change code to use ExecutionAndTraceService from onf-core-model-ap.

Describe your feature request :

Support functionality and forwarding for the service /v1/list-link-uuids , /v1/add-operation-client-to-link, /v1/remove-operation-client-from-link , /v1/list-end-points-of-link

Implementation tasks and next steps :

• Complement the listLInkUuids operation in controller/IndividualServices.js
• Complement the listLInkUuids operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the listLInkUuids operation in controller/IndividualServices.js
• Complement the listLInkUuids operation in services/IndividualServices.js
• support forwarding LinkChangeNotification
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the listLInkUuids operation in controller/IndividualServices.js
• Complement the listLInkUuids operation in services/IndividualServices.js
• support forwarding LinkChangeNotification
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the listEndPointsOfLink operation in controller/IndividualServices.js
• Complement the listEndPointsOfLink operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

The service /v1/regard-application has two callbacks

1. NewApplicationCausesRequestForLatestTopologyInformation - which calls /v1/list-ltps-and-fcs of the regarded application
2. NewApplicationCausesRequestForTopologyChangeInformation - which calls /v1/redirect-topology-change-information of the regarded application

Problem description:
When the regarded application receives /v1/redirect-topology-change-information, ALT receives the regarded application's data through /v1/update-all-ltps-and-fcs (a callback of /v1/redirect-topology-change-information)
However, the request-body of /v1/update-all-ltps-and-fcs and the response-body of /v1/list-ltps-and-fcs are most likely having the same content which might lead ALT receiving the same data twice.

Possible solution:
The callback NewApplicationCausesRequestForLatestTopologyInformation from /v1/regard-application can be removed in order to avoid redundancy.

Describe your feature request :

Support functionality and forwarding for the service /v1/notify-link-updates

Implementation tasks and next steps :

• Complement the notifyLinkUpdatesoperation in controller/IndividualServices.js
• Complement the notifyLinkUpdatesoperation in services/IndividualServices.js
• Forwarding construct configuration LinkChangeNotification
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

In

• /v1/start-application-in-generic-representation :: responses :: consequent-action-list

displayInNewBrowserWindow attribute to be added.

Summary:
As per OAS, the individual service /v1/list-applications should retrieve http-s (application-name and application-release-number) from LTP of all application instances present in the control-construct list. But, the server is retrieving values from http-c of alt-0-0-1.

Example:
The response-body values should be retrieved from /core-model-1-4:network-control-domain/control-construct=/logical-termination-point=-0-0-1-http-s-0000/layer-protocol=0/http-server-interface-1-0:http-server-interface-pac/http-server-interface-capability/application-name and /core-model-1-4:network-control-domain/control-construct=/logical-termination-point=-0-0-1-http-s-0000/layer-protocol=0/http-server-interface-1-0:http-server-interface-pac/http-server-interface-capability/release-number

Instead, the actual values are referred from /core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-http-c-*/layer-protocol=0/http-clienr-interface-1-0:]http-client-interface-pac/http-client-interface-capability/application-name and /core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-http-c-*/layer-protocol=0/http-clienr-interface-1-0:]http-client-interface-pac/http-client-interface-configuration/release-number

As per understanding, detailed-logging-is-on attribute is applicable only for the operation "/v1/record-service-request" of ExecutionAndTraceLog

Problem Description:
In load-file, ApplicationLayerTopology_0.0.2_tsi.220110.1955+data.2.json, for ltp instance alt-0-0-1-op-c-2040 and alt-0-0-1-op-c-2041 contains an additional attribute detailed-logging-is-on, which needs to be removed.
Also an update needed in database/load-file of server

Note :

• alt-0-0-1-op-c-2040 refers to /v1/redirect-topology-change-information
• alt-0-0-1-op-c-2041 refers to /v1/list-ltps-and-fcs

Related issues:
openBackhaul/AdministratorAdministration#40
openBackhaul/OperationKeyManagement#32
openBackhaul/OamLog#41
openBackhaul/ExecutionAndTraceLog#47

Issue#1 :
For the OAM service /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/tcp-server-interface-1-0:tcp-server-interface-pac/tcp-server-interface-configuration/local-address/ipv-4-address , the response-body should have the attribute "tcp-server-interface-1-0:ipv-4-address".
But in the implementation , it is "tcp-server-interface-1-0:local-address"

Proposal : "tcp-server-interface-1-0:local-address" needs to be corrected to "tcp-server-interface-1-0:ipv-4-address"

Issue#2 :
Similarly , for the service /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/tcp-client-interface-1-0:tcp-client-interface-pac/tcp-client-interface-configuration/remote-address/ip-address/ipv-4-address , the response-body should have the attribute "tcp-client-interface-1-0:ipv-4-address".
But in the implementation , it is "tcp-client-interface-1-0:remote-address"

Proposal : "tcp-client-interface-1-0:remote-address" needs to be corrected to "tcp-client-interface-1-0:ipv-4-address"

RelatedIssues :
openBackhaul/RegistryOffice#92
openBackhaul/TypeApprovalRegister#41
openBackhaul/ExecutionAndTraceLog#42
openBackhaul/OamLog#39
openBackhaul/AdministratorAdministration#38
openBackhaul/OperationKeyManagement#29

'String' shall be replaced by 'string' in the OAS of ApplicationPattern and all other applications.

Data structure of the TcpClient and TcpServer shall be complemented by a domainName attribute for preparing potential future appliance of a DNS function.

Modelling has to assure that there is either IP address or domain name communicated and stored.

The following elements of the OAS have to be changed:

• all service bodies containing *address and *port
• all service body examples containing *address and *port
• all service response bodies containing *address and *port
• all service response body examples containing *address and *port
• all callbacks bodies containing *address and *port
• all callbacks body examples containing *address and *port
• all callbacks response bodies containing *address and *port
• all callbacks response body examples containing *address and *port
• control-construct :: tcp-server
• control-construct :: tcp-client

Coding examples:

ip-address:
  type: object
  minProperties: 1
  additionalProperties: false
  properties:
    ipv-4-address:
      type: string
      pattern: '^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$'
      description: >
        '..'
domain-name:
  type: string
  pattern: '^([a-z0-9]+(-[a-z0-9]+)*\.)+[a-z]{2,}$'
  description: >
    '..'

example:
  new-application-name: 'NewApplicationName'
  new-application-release: '0.0.2'
  new-application-address:
    ip-address:
      ipv-4-address: '10.118.125.157'
  new-application-port: 7000

Further details can be found in the callbacks inside the ApplicationPattern OAS.

As a part of bequeath-your-data-and-die service , relay-server-replacement will be called by the old application to replace the old release with the new release. This relay-server-replacement service is getting called twice from the old application which is unnecessary.
This needs to be fixed in the server side code.

Note : There is no problem in calling the service twice as it is idempotent, but it is not required.

Describe your feature request :

Generate server side code for the specification

Implementation tasks and next steps :

• Generate server side stub for the latest specification https://github.com/openBackhaul/ApplicationLayerTopology/blob/tsi/ApplicationLayerTopology_0.0.2_tsi.220110.1955.yaml
• Add the required dependencies in the package.json

Alternate proposals if any :

Additional context :

The following services are used to update(add/delete) ltp objects of other applications in the microservice architecture to the ApplicationLayerTopology application.

1. /v1/update-ltp
2. /v1/delete-ltp-and-dependents
3. /v1/update-fc
4. /v1/update-fc-port
5. /v1/delete-fc-port

The request body of this services holds the object(ltp/fc/fc-port) that needs to be updated(added/deleted). In addition to this , it would be helpful if we also include the "control-construct::uuid". So that we can identify the correct instance in the control-construct list by using this "control-construct::uuid" as a key.

Note : Without this attribute "control-construct::uuid" also we can perform the above mentioned 5 operations by extracting the control-construct::uuid from the uuid of the ltp or forwarding construct.

While triggering /v1/bequeath-your-data-and-die, a series of callbacks will be called to other applications for scenarios like transferring application specific data, creating/ending subscriptions.
While the callbacks are being triggered from the application, we could observe an unexpected behavior.

Problem:
The server is abruptly stopped with an error message thrown after the callback request fails.
Error message :

${forwarding} is not success for the input[object Object] node:internal/process/promises:246
triggerUncaughtException(err, true /* fromPromise */);

Expected behavior:
When any callback request fails, /v1/bequeath-your-data-and-die should not proceed further for next callback. The application should not stop abruptly and it runs normally.

Related issues:
openBackhaul/RegistryOffice#96
openBackhaul/TypeApprovalRegister#45
openBackhaul/ExecutionAndTraceLog#48
openBackhaul/OamLog#43
openBackhaul/AdministratorAdministration#42
openBackhaul/OperationKeyManagement#34

/v1/delete-fc-port accepts two attributes in the request-body, fc-uuid and fc-port-local-id

Expectation:
As per idempotence condition, when the request-body contains an "fc-uuid" or "fc-port-local-id" that are not present in the load-file, the server should return 204 (with no changes in the load-file)

Currently, the expectation is satisfied for "fc-port-local-id", as the server returns 204 even if the expected local-id is not present in the load-file.

Problem:
But, when the request-body contains an unknown fc-uuid, the server throws an exception

(TypeError: Cannot read properties of undefined (reading 'forwarding-domain') at getAttributeValueFromDataBase (..\server\applicationPattern\databaseDriver\JSONDriver.js:129:66))

Also, the server is not returning any value to the response. This behavior needs to be handled.

The servers statement at the beginning of the OAS, does not provide any benefit.
It should be removed.

This applies to the ApplicationPattern and all applications.

In the load file ApplicationLayerTopology_0.0.2_tsi.220110.1955+data.1 , for the uuid alt-0-0-1-op-s-3021 in logical-termination-point list , closing quotation mark is missing. (This creates a parsing error while trying to read the json file from application )

Currently , the apiKeyAuth and basicAuth validations are handled in the controllers/ for each services in their corresponding methods.
This validation in each methods can be replaced by integrating the security check mechanism as a part of express framework instantiation.

Reference : OperationKeyManagement

The summary of the service /v1/delete-ltp-and-dependents is as below,

An OperationClient identified by LtpUuid and all its entries in FCs and Links gets deleted

But as per the requestBody/uuid description , by using this service , we can delete any ltp,

LtpUuid identifying the LTP, which is to be deleted find in [/core-model-1-4:network-control-domain/control-construct=*-0-0-1/logical-termination-point=*-0-0-1-*-*-*/uuid]

Kindly let me know whether we have to change the summary text.

Describe your feature request :

Support functionality and forwarding for the service /v1/list-operation-servers-at-application, /v1/list-operation-clients-at-application

Implementation tasks and next steps :

• Complement the listOperationServersAtApplication operation in controller/IndividualServices.js
• Complement the listOperationServersAtApplication operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the listOperationClientsAtApplication operation in controller/IndividualServices.js
• Complement the listOperationClientsAtApplication operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

In application pattern, all services in Service Layer contains customized response-headers (exec-time, backend-time, life-cycle-state, x-correlator). These headers are absent in response of /v1/list-applications which need to be added

The service /v1/notify-link-updates is a service that enables OperationKeyManagement application to subscribe for any update in links.

Error description:
In description of the request-body attributes, the reference path points to random application (like alt-0-0-1-http-c-*)

Proposal:
The reference paths of all attributes could be made specific to OKM.

For example,
for subscriber-application , currently the path is /core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-http-c-*/layer-protocol=0/http-client-interface-1-0:http-client-interface-pac/http-client-interface-capability/application-name which could be changed to /core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point=alt-0-0-1-http-c-2080/layer-protocol=0/http-client-interface-1-0:http-client-interface-pac/http-client-interface-capability/application-name

Similarly paths could be changed for attributes

• subscriber-release-number (alt-0-0-1-http-c-2080)
• subscriber-operation (alt-0-0-1-op-c-3080)
• subscriber-address (alt-0-0-1-tcp-c-2080)
• subscriber-port (alt-0-0-1-tcp-c-2080)

Describe your feature request :

Support functionality and forwarding for the service /v1/start-application-in-generic-representation

Implementation tasks and next steps :

• Complement the startApplicationInGenericRepresentation operation in controller/IndividualServices.js
• Complement the startApplicationInGenericRepresentation operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

In the load file of ALT , we have the following forwarding constructs from ALT to ALT for updating LTPs,

For example , for v1/regard-application , after creating LTPs for a new application, the same LTPs will be updated again by using the operation-client v1/update-ltp. Kindly Please let us know whether we have specific reason behind this or can we remove this forwardings from the load file ?

problem description:
In load-file ApplicationLayerTopology_0.0.2_tsi.220110.1955+data.2.json, the uuid "alt-0-0-1-op-c-2041" is missing in the client-ltp list for alt-0-0-1-http-c-0040 , which needs to be added

Note :

• alt-0-0-1-http-c-0040 refers to ExecutionAndTraceLog
• alt-0-0-1-op-c-2041 refers to /v1/list-ltps-and-fcs

Problem description
For PUT request in OAM layer , after successful updation , server is returning 200 OK as the ResponseCode.
As per the specification and generic concepts, this is not correct.

Proposed solution
Since the PUT operation doesn't return any value in the ResponseBody , the ResponseCode should be 204 NO_CONTENT.

• Add ActionProfile to /core-model-1-4:control-construct:
• Add - 'action-profile-1-0:PROFILE_NAME_TYPE_GENERIC_DISPLAY_PROFILE' to all Profiles in /core-model-1-4:control-construct:
• Update all consequent-action-lists with Descriptions referencing the ActionProfile
• Add ActionProfiles to LOADfile
• Add ActionProfiles to ProfileList

Describe your feature request :

Support functionality and forwarding for the service /v1/bequeath-your-data-and-die to perform version upgrade

Implementation tasks and next steps :

• Complement the BequeathYourDataAndDie operation in controller/IndividualServices.js
• Complement the BequeathYourDataAndDie operation in services/IndividualServices.js
• Support forwardings PromptForBequeathingDataCausesTransferOfListOfApplications
• Support forwardings PromptForBequeathingDataCausesTransferOfLtpsAndFcs
• Support forwardings PromptForBequeathingDataCausesTransferOfLinkInformation
• Support forwardings PromptForBequeathingDataCausesRObeingRequestedToNotifyApprovalsOfNewApplicationsToNewRelease
• Support forwardings PromptForBequeathingDataCausesRObeingRequestedToNotifyWithdrawnApprovalsToNewRelease
• Support forwardings PromptForBequeathingDataCausesRObeingRequestedToStopNotificationsToOldRelease
• Support forwardings PromptForBequeathingDataCausesRequestForBroadcastingInfoAboutServerReplacement
• Support forwardings PromptForBequeathingDataCausesRequestForDeregisteringOfOldRelease
• Support forwardings ServiceRequestCausesLtpUpdateRequest
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

Describe your feature request :

Include implementation for the Individual services of Application layer topology

Implementation tasks and next steps :

• complete #12
• complete #13
• complete #14
• complete #15
• complete #16
• complete #17
• complete #18
• complete #19
• complete #20
• complete #21

Alternate proposals if any :

Additional context :

Describe your feature request :

Include support for basic services

Implementation tasks and next steps :

• Include basic services
• Test the integrated fucntionality
• commit and merge the changes

Alternate proposals if any :

Additional context :

Describe your feature request :

Support functionality and forwarding for the service /v1/update-fc , /v1/update-fc-port, /v1/delete-fc-port

Implementation tasks and next steps :

• Complement the updateFc operation in controller/IndividualServices.js
• Complement the updateFc operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the updateFcPort operation in controller/IndividualServices.js
• Complement the updateFcPort operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the deleteFcPort operation in controller/IndividualServices.js
• Complement the deleteFcPort operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

Describe your feature request :

Include support for OAM Services

Implementation tasks and next steps :

• Include basic services
• Test the integrated fucntionality
• commit and merge the changes

Alternate proposals if any :

Additional context :

In the initial load file(ApplicationLayerTopology_0.0.2_tsi.220110.1955+data.2.json) , the operation-name of the operation-server alt-0-0-1-op-s-0002 is /v1/redirect-topology-change-information.
This needs to be changed to /v1/redirect-service-request-information.

Additional information
The /v1/redirect-topology-change-information operation is available in "alt-0-0-1-op-s-0009".

problem description:
In load-file ApplicationLayerTopology_0.0.2_tsi.220110.1955+data.2.json,

1. the uuid "alt-0-0-1-op-c-2301" is missing from the client-ltp list of alt-0-0-1-http-c-2300 , which needs to be added
2. the uuid "alt-0-0-1-tcp-c-2301" in server-ltp list of alt-0-0-1-http-c-2300 needs to be removed. (also in server/database/load-file.json)

Note:

• alt-0-0-1-http-c-2300 refers to CurrentController
• alt-0-0-1-op-c-2301 refers to /v1/list-ltps-and-fcs

In /v1/update-all-ltps-and-fcs and /v1/update-ltp services , in the request body of the operation-server/client-interface-configuration object , the attribute operation-key is missing. Also please refer issue#3

For /v1/update-all-ltps-and-fcs , in the request body this keyword is missing,

For /v1/update-ltp , in the request body this keyword is missing,

Note : Kindly please change the label to "bug" if it is.

Describe your feature request :

Support functionality and forwarding for the service /v1/update-all-ltps-and-fcs, /v1/update-ltp, /v1/delete-ltp-and-dependents

Implementation tasks and next steps :

• Complement the updateAllLtpsAndFcs operation in controller/IndividualServices.js
• Complement the updateAllLtpsAndFcs operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the updateLtp operation in controller/IndividualServices.js
• Complement the updateLtp operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the deleteLtpAndDependents operation in controller/IndividualServices.js
• Complement the deleteLtpAndDependents operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

In the yaml specification -> basic services -> description of each property -> the reference path URI structure is being left in the format followed earlier in other tiny applications, here which would be following the format like [/core-model-1-4:network-control-domain/control-construct=*/]..

for example, In the service request /v1/register-yourself , under description of the property registry-office-application, it is “find or create [/core-model-1-4:control-construct/logical-termination-point=*-0-0-1-http-c-0020/layer-protocol=0/http-client-interface-1-0:http-client-interface-pac/http-client-interface-capability/application-name]”, which would be actually “/core-model-1-4:network-control-domain/control-construct=alt-0-0-1/logical-termination-point={uuid}/layer-protocol=0/http-client-interface-1-0:http-client-interface-pac/http-client-interface-capability/application-name”.

Similar occurrences of older reference URI could be found in other properties of the same request as well as in the other requests under Basic services of ALT.

Describe your feature request :

Include implementation for the specification of Application layer topology V0.0.2

Implementation tasks and next steps :

• complete #24
• complete #22
• complete #23
• complete #25

Alternate proposals if any :

Additional context :

As per the description , this service provides current operationKey of the operation identified by the provided uuid in the request body.
And as per the description of the uuid , it is ‘find [/core-model-1-4:network-control-domain/control-construct=*/logical-termination-point=*-0-0-1-op-*-*/uuid]'

Please correct me whether my following understandings are correct ?

1. Current operation-key for all application’s operation-client/server in the MS environment will be retrieved by using this service ?
2. (If yes for point#1 ? then ) when the service /v1/provide-current-operation-key is called with input “ro-0-0-1-op-s-0001” , we have to find the control-construct instance with the uuid “ro-0-0-1” and further the ltp with uuid “ro-0-0-1-op-s-0001” ?
3. (If yes for point#1? then ) whether we have to include operation-key to the operation-server/client-interface-configuration object of the request body of /v1/update-all-ltps-and-fcs and /v1/update-ltp ? Also Please refer issue#2

Describe your feature request :

Support functionality and forwarding for the service /v1/list-links-to-operation-clients-of-application

Implementation tasks and next steps :

• Complement the listLinksToOperationClientsOfApplication operation in controller/IndividualServices.js
• Complement the listLinksToOperationClientsOfApplication operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :

Problem:

Operation-name is statically defined in callback request "NewApplicationCausesRequestForLatestTopologyInformation" and "NewApplicationCausesRequestForTopologyChangeInformation"

Proposal:

• Line 1488 to be changed from "https://{$request.body#application-address}:{$request.body#application-port}/v1/list-ltps-and-fcs" to "https://{$request.body#application-address}:{$request.body#application-port}[/core-model-1-4:control-construct/logical-termination-point=alt-0-0-1-op-s-0008/layer-protocol=0/operation-client-interface-1-0:operation-client-interface-pac/operation-client-interface-configuration/operation-name]"
• Line 1882 to be changed from "https://{$request.body#application-address}:{$request.body#application-port}/v1/redirect-topology-change-information" to "https://{$request.body#application-address}:{$request.body#application-port}[/core-model-1-4:control-construct/logical-termination-point=alt-0-0-1-op-s-0009/layer-protocol=0/operation-client-interface-1-0:operation-client-interface-pac/operation-client-interface-configuration/operation-name]"

Related issue : openBackhaul/OamLog#6

Describe your feature request :

Include docker file to create docker image

Implementation tasks and next steps :

• Create docker file including the following :

1. Create app directory
2. Install and app dependencies
   2.1. use a wildcard to ensure both package.json AND package-lock.json are copied
   2.2. RUN npm install
3. Bundle app source
4. Command to start the application

• Test whether this docker file is creating a docker image

Alternate proposals if any :

Additional context :

Describe your Issue :

In the server implementation of ALT , the response body of /v1/list-end-points-of-link is not in the kebab-case as defined in the OAS ,

{"link-end-point-list": [{
"operationUuid": "alt-0-0-1-op-s-3017",
"ltpDirection": "core-model-1-4:TERMINATION_DIRECTION_SOURCE",
"applicationName": "ApplicationLayerTopology",
"releaseNumber": "0.0.1"
}]}

Implementation tasks and next steps :
The response body needs to be correct as per the specification.

Alternate proposals if any :

Additional context :

Describe your feature request :

Support functionality and forwarding for the service /v1/regard-application , /v1/disregard-application, /v1/list-applications.

Implementation tasks and next steps :

• Complement the regardApplication operation in controller/IndividualServices.js
• Complement the regardApplication operation in services/IndividualServices.js
• Support forwarding configuration NewApplicationCausesRequestForLatestTopologyInformation
• Support forwarding configuration NewApplicationCausesRequestForTopologyChangeInformation
• Support forwarding ServiceRequestCausesLtpUpdateRequest
• Support forwarding ServiceRequestCausesFcUpdateRequest
• Support forwarding NewApplicationCausesRequestForLatestTopologyInformation
• Support forwarding NewApplicationCausesRequestForTopologyChangeInformation
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the disregardApplication operation in controller/IndividualServices.js
• Complement the disregardApplication operation in services/IndividualServices.js
• Support forwarding unconfiguration NewApplicationCausesRequestForLatestTopologyInformation
• Support forwarding unconfiguration NewApplicationCausesRequestForTopologyChangeInformation
• Support forwarding ServiceRequestCausesLtpDeletionRequest
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log
• Complement the listApplications operation in controller/IndividualServices.js
• Complement the listApplications operation in services/IndividualServices.js
• Support forwarding ServiceRequestCausesLoggingRequest to Execution and Trace Log

Alternate proposals if any :

Additional context :