[INFRAUTILS-27] Ready API for more fine grained per-bundle notifications Created: 22/Nov/17 Updated: 29/Sep/20 Resolved: 29/Sep/20 |
|
| Status: | Resolved |
| Project: | infrautils |
| Component/s: | ready |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Medium |
| Reporter: | Michael Vorburger | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
k.faseela (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.SystemReadyMonitor should either allow another registerListener(), or we could directly extend the existing SystemReadyListener, to get notified not only of onSystemBootReady() as we have, but also onBundleActive(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). |
| Comments |
| Comment by Michael Vorburger [ 28/Nov/17 ] |
|
Design: I'll build this on top of the change in |
| Comment by Michael Vorburger [ 28/Nov/17 ] |
|
https://git.opendaylight.org/gerrit/#/c/66030/ for odlparent; I'll do the infrautils part when that is merged. |
| Comment by Michael Vorburger [ 28/Feb/18 ] |
| Comment by Michael Vorburger [ 09/May/18 ] |
|
FTR: k.faseela 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... |
| Comment by Michael Vorburger [ 09/May/18 ] |
|
> 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 k.faseela does this help to further investigate? Now notifying all its registered SystemReadyListeners... |
| Comment by Robert Varga [ 29/Sep/20 ] |
|
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. 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.
|