IswaryaaS
commented
1 year ago Closing this issue as it would be followed up in https://github.com/openBackhaul/ApplicationPattern/issues/686 because the issue is more generalized for updating services in ApplicationPattern
We have few subscriptions in RO namely /v1/notify-deregistrations, /v1/notify-approvals and /v1/notify-withdrawn-approvals which shall create new http-c, tcp-c and op-c for a new application to RO is trying to subscribe. (reference issue : https://github.com/openBackhaul/RegistryOffice/issues/344 - conversation for having subscriptions to create new ltp instances)
Problem: As per current design, if we need to deregister these subscribed application, a direct hit of /v1/deregister-application shall only delete http-c, tcp-c and op-c and not fc-port created under Subscription forwarding-constructs like DeregistrationNotification, ApprovalNotification and WithdrawnApprovalNotification. For deleting fc-port, we would /v1/end-subscription should be triggered first followed by /v1/deregister-application.
Proposal: I hope, /v1/deregister-application shall be deleting all the instances of ltp and fc-port instances in config file irrespective of subscriptions. Also, if any application accidentally triggering /v1/deregister-application before /v1/end-subscription, the corresponding fc-ports will be left behind. Also, as per above case, even if we directly trigger /v1/deregister-application, fc-ports under DeregistrationNotification, ApprovalNotification and WithdrawnApprovalNotification shall also be deleted.
Including management port for /v1/deregister-application - ro-2-0-1-op-s-is-002 to forwarding-constructs DeregistrationNotification, ApprovalNotification and WithdrawnApprovalNotification would solve this problem
Kindly let us know your views.