Ready API for more fine grained per-bundle notifications
Description
blocks
is blocked by
Activity
Robert Varga September 29, 2020 at 8:37 PM
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.
This is not true, really, as our dependencies are already expressed at a much lower level, which is services. https://lf-opendaylight.atlassian.net/browse/CONTROLLER-1882#icft=CONTROLLER-1882 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).
In static environments the entity performing service stitching is responsible for driving components correctly, so that they have reached initial readiness.
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.
Michael Vorburger May 9, 2018 at 10:22 AM
> should be looked at...
it has those lines:
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.]but it's missing this which I think normally we see, because OFP or diagtatus or something registers a SystemReadyListener @Faseela K does this help to further investigate?
Now notifying all its registered SystemReadyListeners...Michael Vorburger May 9, 2018 at 10:17 AM
FTR: @Faseela K yesterday merged c/68872 but today had to revert it (in c/71887) because somehow this broke CSIT - we'll investigate how; apparently this https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-gate-all-fluorine/49/odl1_karaf.log.gz should be looked at...
Michael Vorburger November 28, 2017 at 9:14 PMEdited
https://git.opendaylight.org/gerrit/#/c/66030/ for odlparent; I'll do the infrautils part when that is merged.
@Faseela K (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:
org.opendaylight.infrautils.ready.SystemReadyMonitorshould either allow another registerListener(), or we could directly extend the existingSystemReadyListener, to get notified not only ofonSystemBootReady()as we have, but alsoonBundleActive(String bundleSymbolicName).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).