https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-547 netconf <p>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.</p> NETCONF-547

RESTCONF should wait for system ready to open 8181

Improvement Medium Open Unresolved Faseela K Faseela K Fri, 8 Jun 2018 05:25:12 +0000 Tue, 2 Oct 2018 11:54:42 +0000 0 3 <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=thapar" class="user-hover" rel="thapar">thapar</a> : Any free cycles to work on this? <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Hi <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a>, do you plan to work on this?</p> <p>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.</p> <p>Jakub <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=JMorvay" class="user-hover" rel="JMorvay">JMorvay</a> , this is definitely on my to-do list, but am currently on vacation.. had discussed with <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vorburger" class="user-hover" rel="vorburger">vorburger</a> about this sometime back and created the jira for tracking.. let us discuss about this once am back..(only in November)</p> <p>&gt; we don't have dependency on infrautils</p> <p>netconf could add a dependency on infrautils, of course?  </p> <p>&gt; so we need to figure out restconf/netconf stack readiness somehow on our own</p> <p>even <a href="https://docs.google.com/presentation/d/1C2jbZP8C8FwoR9yoFMrMs-kKt8Uiv8r8vtXc1bocb7c/edit#slide=id.g42351b3c54_0_0" class="external-link" target="_blank" rel="nofollow noopener">the infrautils diagstatus thing</a>, 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.</p> <p>But I have a question: How/when/where exactly does restconf &amp; netconf actually <em>"open up external facing ports"</em> ? 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 <tt>@PostConstruct</tt> of some BP <tt>@Singleton</tt> (<tt>&lt;bean&gt;</tt>), then infrautils.ready will already check for any failure and report them correctly. The only reason why an explicit <a href="https://github.com/opendaylight/infrautils/blob/master/diagstatus/api/src/main/java/org/opendaylight/infrautils/diagstatus/ServiceStatusProvider.java" class="external-link" target="_blank" rel="nofollow noopener">ServiceStatusProvider</a> in restconf/netconf would be useful would be if it did more "dynamically" open and close ports, after the Blueprint boot - but does it? <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> may have some input here as well. Just to illustrate further, the <a href="https://github.com/opendaylight/genius/blob/f38ca7769fcdf39573ad37c73f9e49685ee224f5/interfacemanager/interfacemanager-impl/src/main/java/org/opendaylight/genius/interfacemanager/diagstatus/IfmDiagStatusProvider.java" class="external-link" target="_blank" rel="nofollow noopener">IFM</a> and <a href="https://github.com/opendaylight/genius/blob/f38ca7769fcdf39573ad37c73f9e49685ee224f5/itm/itm-impl/src/main/java/org/opendaylight/genius/itm/diagstatus/ItmDiagStatusProvider.java" class="external-link" target="_blank" rel="nofollow noopener">ITM status providers</a> 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 &amp; blueprint) start already tells us, whereas the <a href="https://github.com/opendaylight/genius/blob/7b0d5dda05fdff7a3c66cb556fe9b7b58191ee97/mdsalutil/mdsalutil-impl/src/main/java/org/opendaylight/genius/mdsalutil/diagstatus/internal/DatastoreServiceStatusProvider.java" class="external-link" target="_blank" rel="nofollow noopener">DatastoreServiceStatusProvider</a> adds real value, because it provides monitoring insight into a dynamically changing state.</p> Development Rank 0|i03fgf: