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/INFRAUTILS-27 infrautils <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a> (in private email) expressed interest in infrautils.ready be able to report more fine grained per-bundle notifications. She would like to consume this in infrautils.diagstatus, and said specifically this would be useful for her:</p> <p><tt>org.opendaylight.infrautils.ready.SystemReadyMonitor</tt> should either allow another registerListener(), or we could directly extend the existing <tt>SystemReadyListener</tt>, to get notified not only of <tt>onSystemBootReady()</tt> as we have, but also <tt>onBundleActive(String bundleSymbolicName)</tt>. </p> <p>There is of course already lower level pure OSGi API for something lie this, but infrautils.ready should do it integrated with Blueprint - probably based on the odlparent TestBundleDiag thing (which may need an extension for this).</p> INFRAUTILS-27

Ready API for more fine grained per-bundle notifications

Improvement Medium Resolved Won't Do Unassigned Michael Vorburger Wed, 22 Nov 2017 16:34:52 +0000 Tue, 29 Sep 2020 20:37:18 +0000 Tue, 29 Sep 2020 20:37:18 +0000 ready 0 1 <p>Design: I'll build this on top of the change in <a href="https://jira.opendaylight.org/browse/INFRAUTILS-17" title="BundleDiagInfos Missing dependencies logs in working distros" class="issue-link" data-issue-key="INFRAUTILS-17"><del>INFRAUTILS-17</del></a>, which exposes the BundleDiagInfos during TestBundleDiag checkBundleDiagInfos. Then we can add this more fine-grained Bundle-based info to be exposed to BundleDiagInfos, which SystemReadyImpl can then exploit and do stuff with - such as invoke such a new listener.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/66030/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/66030/</a> for odlparent; I'll do the infrautils part when that is merged.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/68872/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/68872/</a></p> <p>FTR: <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a> yesterday merged c/68872 but today had to revert it (in c/71887) because somehow this broke CSIT - we'll investigate how; apparently this <a href="https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-gate-all-fluorine/49/odl1_karaf.log.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-gate-all-fluorine/49/odl1_karaf.log.gz</a> should be looked at...</p> <p>&gt; should be looked at...</p> <p>it has those lines:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2018-05-09T09:26:53,172 | INFO | awaitility[checkBundleDiagInfos] | SystemReadyImpl | 356 - org.opendaylight.infrautils.ready-impl - 1.4.0.SNAPSHOT | checkBundleDiagInfos: Elapsed time 10s, remaining time 289s, diag: Active {Installed=0, Resolved=6, Unknown=0, GracePeriod=0, Waiting=0, Starting=0, Active=532, Stopping=0, Failure=0} 2018-05-09T09:26:53,180 | INFO | SystemReadyService-0 | TestBundleDiag | 356 - org.opendaylight.infrautils.ready-impl - 1.4.0.SNAPSHOT | diag: Active {Installed=0, Resolved=6, Unknown=0, GracePeriod=0, Waiting=0, Starting=0, Active=532, Stopping=0, Failure=0} 2018-05-09T09:26:53,181 | INFO | SystemReadyService-0 | SystemReadyImpl | 356 - org.opendaylight.infrautils.ready-impl - 1.4.0.SNAPSHOT | System ready; AKA: Aye captain, all warp coils are now operating at peak efficiency! [M.]</pre> </div></div> <p>but it's missing this which I think normally we see, because OFP or diagtatus or something registers a <tt>SystemReadyListener</tt> <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a> does this help to further investigate?</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Now notifying all its registered SystemReadyListeners...</pre> </div></div> <p>There is an unspoken assumption in this issue that we are using BluePrint and have a lifecycle tied to that – which in fact operates on bundle level and usually sees all components thrown into a single BP container.</p> <p>This is not true, really, as our dependencies are already expressed at a much lower level, which is services. <a href="https://jira.opendaylight.org/browse/CONTROLLER-1882" title="Inject DataBroker only when all shards have leaders" class="issue-link" data-issue-key="CONTROLLER-1882"><del>CONTROLLER-1882</del></a> has been implemented and it ensures that services are only injected after they have reached initial convergence. These operate on OSGi Declarative Services, hence are much more granular than bundle-level and map properly to OSGi service lifecycle (unlike BluePrint).</p> <p>In static environments the entity performing service stitching is responsible for driving components correctly, so that they have reached initial readiness.</p> <p>What happens if the services become un-ready, is a whole another issue. OSGi provides one environment which solves the question (via service deactivation and rewiring). For other environments that question may be in appropriate, or have a wildly different answer – and is not really something which would be in scope for an SDN controller.</p> <p> </p> Blocks INFRAUTILS-11 INFRAUTILS-17 Relates TSC-117 Development Rank 0|i038dz: