[NETCONF-547] RESTCONF should wait for system ready to open 8181 Created: 08/Jun/18  Updated: 02/Oct/18

Status: Open
Project: netconf
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Medium
Reporter: Faseela K Assignee: Faseela K
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

infrautils.systemReady provides a mechanism to register for notifications to know when a system is really UP. It would be great if restconf uses this to open up external facing ports, so that we don't end up accepting northbound requests when we are really not ready to process it end to end.



 Comments   
Comment by Faseela K [ 20/Jun/18 ]

thapar : Any free cycles to work on this?

Comment by Jakub Morvay [ 01/Oct/18 ]

Hi k.faseela, do you plan to work on this?

This can be nice improvement, but currently (at least to my knowledge) we don't have dependency on infrautils, so we need to figure out restconf/netconf stack readiness somehow on our own.

Comment by Faseela K [ 02/Oct/18 ]

Jakub JMorvay , this is definitely on my to-do list, but am currently on vacation.. had discussed with vorburger about this sometime back and created the jira for tracking.. let us discuss about this once am back..(only in November)

Comment by Michael Vorburger [ 02/Oct/18 ]

> we don't have dependency on infrautils

netconf could add a dependency on infrautils, of course?  

> so we need to figure out restconf/netconf stack readiness somehow on our own

even the infrautils diagstatus thing, restconf/netconf would need to figure out its stack readiness on its own... but it would be able to communicate that status to the overall solution package, which is very important for real world operational monitorability, e.g. via the /diagstatus URL.

But I have a question: How/when/where exactly does restconf & netconf actually "open up external facing ports" ? I'm asking because if all it does is register servlets with our Web API (from aaa.web), then I'm not sure if there really is anything to do here... if that happens in a constructor or @PostConstruct of some BP @Singleton (<bean>), then infrautils.ready will already check for any failure and report them correctly. The only reason why an explicit ServiceStatusProvider in restconf/netconf would be useful would be if it did more "dynamically" open and close ports, after the Blueprint boot - but does it? tpantelis may have some input here as well. Just to illustrate further, the IFM and ITM status providers are actually completely useless (and really should be removed as still not implemented with anything providing real dynamic status data), because they don't really add any value beyond what the "technical readyness" (bundle & blueprint) start already tells us, whereas the DatastoreServiceStatusProvider adds real value, because it provides monitoring insight into a dynamically changing state.

Generated at Wed Feb 07 20:15:18 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.