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-11 infrautils <p>Previous discussions, incl. a session at last year's ODL DDF, have repeatedly identified the need to have a general way to reliably detect when ODL is "ready".</p> <p>Today projects sometimes have ad-hoc solution for this; for example netvirt's org.opendaylight.netvirt.statemanager.StateManager (which logs "StateManager all is ready") is related to (the lack of a general solution for) this.</p> <p>I've hit what's basically the same gap again while contributing an "auto-import-on-boot" feature to the Daexim project in <a href="https://git.opendaylight.org/gerrit/#/c/55035/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/55035/</a>, where the Daexim committers would like that feature to hold importing until "the system is full ready" (I don't fully understand why, but that is not the point of this bug), and will therefore as part of the work I'm doing in that context contribute a general new Ready Service, to infrautils.</p> <p>This will build on top of the work I've done for the Extended SingleFeatureTest (SFT) incl. TestBundleDiag in odlparent (see e.g. <a href="https://lists.opendaylight.org/pipermail/release/2017-January/009062.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/release/2017-January/009062.html</a>), and actually re-use that same code.</p> <p>The first contribution for this will be minimalistic and fulfil the immediate need I have (in Daexim). Later Enhancements by others or myself on top of that first iteration can then obviously extend it; ideas for possible future follow-up improvements which won't be in my initial proposal include but are not limited to:</p> <p>1. YANG model to expose the simple API I'll offer as RESTCONF etc. RPC</p> <p>2. YANG data model which sets a flag in the data store (like netvirt's StateManager)</p> <p>3. JMX ?</p> <p>3. ...</p> <p>Operating System: All<br/> Platform: All</p> INFRAUTILS-11

Ready service

Improvement Medium Resolved Done Michael Vorburger Michael Vorburger Wed, 10 May 2017 20:40:53 +0000 Mon, 19 Mar 2018 21:28:17 +0000 Thu, 15 Mar 2018 10:20:41 +0000 Nitrogen Oxygen General 0 13 <p>Doesn't daexim really want to have the data store and models ready, but applications not started?</p> <p>&gt; Doesn't daexim really want to have the data store <br/> &gt; and models ready, but applications not started?</p> <p>I've no idea; but that is not the point of this bug... New <a href="https://jira.opendaylight.org/browse/DAEXIM-3" title="New &quot;auto-import-on-boot&quot; feature" class="issue-link" data-issue-key="DAEXIM-3"><del>DAEXIM-3</del></a> open in Daexim now.</p> <p>&gt; contribute a general new Ready Service, to infrautils</p> <p>==&gt; <a href="https://git.opendaylight.org/gerrit/#/c/56749/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/56749/</a>, basic v1 done from my end and ready for general review now; I'm hoping hoping to merge that soon-ish (i.e. "days, not weeks"). I'll be raising a separate follow-up Gerrit to add Karaf 3 support on top of above.</p> <p>We are interested in using this functionality to know when a restore procedure is really finished.</p> <p>&gt; <a href="https://bugs.opendaylight.org/show_bug.cgi?id=9165#c9" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=9165#c9</a></p> <p>Responding here, as <a href="https://jira.opendaylight.org/browse/CONTROLLER-1771" title="Add INFO log when config subsystem finishes applying initial configurations" class="issue-link" data-issue-key="CONTROLLER-1771"><del>CONTROLLER-1771</del></a> was opened just for a simple logging change.</p> <p>I have never studied software design, so here is my list of ad-hoc ideas.</p> <p>What is the "northbound" for this service? Both it term of mechanism (Just write to operational datastore, or provide some other publishing method?) and amount of data presented (Will there be timestamps? Will there be IDs to identify currently un-ready components?).</p> <p>Cluster-wide or local member only?</p> <p>What about granularity? For example, topology-netconf might be ready, but when detecting configuration change (initiating a connect attempt to a netconf device) should the device connector be regarded as a sub-component with its own readiness? Can we create a hierarchy of such sub-components in an easy fashion? (Our own implementation of ListenableFuture which notifies the readiness service?)</p> <p>Do we want to report readiness, or quiescence (or both)? In the previous example, while device connector is not ready, topology-netconf (as a service) is ready, but not quiet (as the device operational status is in transient state).</p> <p>In CSIT we would use both. Global quiescence in <del>only</del> jobs to ensure conditions are repeatable (and karaf.log clean), fine-grained readiness in <del>all</del> jobs to speed up test execution while making sure the functionality works even if ODL is not quiet yet.</p> <p>What if a sub-component fails (connection to netconf device refused). Should the sub-component report readiness when it processes the failure? Can super-component "unregister" the sub-component when performing cleanup? Do we want a Failure Service?</p> <p>Any leaks we should think about before finalizing our design?<br/> If a sub-component did not register and is garbage collected, we want to let the garbage collection happen even if it has registered (and unregister it).</p> <p>Changing Target from Nitrogen to Oxygen. Pending:</p> <ul> <li><a href="https://git.opendaylight.org/gerrit/#/c/56821/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/56821/</a></li> <li><a href="https://git.opendaylight.org/gerrit/#/c/61480/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/61480/</a> (plus it's impl follow-up)</li> <li>Faseela's "diagstatus" work (in infrautils) - and how it integrates with "ready"</li> </ul> <p>I'm definitely wanting to close this general "launch" issue within Oxygen, and then have more specific follow-up new issues (linked here as Blocks) for future extensions...</p> <p>&gt; What is the "northbound" for this service? </p> <p>I'm not sure how you mean the term "northbound" in this context - I always understood "northbound" as RESTCONF API - whereas infrautils.ready is lower-level, just an internal OSGi service.</p> <p>&gt; write to operational datastore, or provide some other publishing method?</p> <p>infrautils.ready itself will never write to the operational datastore (because infrautils will never depend on controller/mdsal), BUT infrautils.diag is proposing a CLI command which among other things will also expose infrautils.ready's status, after we merge .</p> <p>You can find out more about infrautils.diag in the spec on <a href="https://git.opendaylight.org/gerrit/#/c/51171/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/51171/</a></p> <p>Another project, perhaps genius will, could write the infrautils.ready status and/or the infrautils.diag services status into MDSAL - if someone needs that and wants to contribute this.</p> <p>And infrautils.ready happily spams the log, with the same information that you get from SFT, now included at run-time.</p> <p>&gt; Will there be timestamps? </p> <p>Not in the API/CLI, no, because it's not "historical". Yes in the LOG.</p> <p>&gt; Will there be IDs to identify currently un-ready components?).</p> <p>infrautils.diag has something a bit like this, but not 100% sure.</p> <p>&gt; Cluster-wide or local member only?</p> <p>Currently infrautils.ready reports local status only.</p> <p>infrautils.diag has an upcoming CLI command to query the entire cluster's status, see <a href="https://git.opendaylight.org/gerrit/#/c/62900/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/62900/</a></p> <p>&gt; What about granularity? </p> <p>infrautils.ready's scope is the OSGi bundles.</p> <p>infrautils.diag's scope is (possible N several) "functional services" within those bundles. It currently has no notion of hierarchy, but if you feel strongly that this could be of value, then perhaps it is something you'd like to open a separate new enhancement issue for, and discuss further (likely more with Faseela than with me) over there.</p> <p>&gt; Do we want to report readiness, or quiescence (or both)? </p> <p>infrautils.ready reports readiness of OSGi bundles (incl. their BP state).</p> <p>I'm not sure yet how quiescence relates to this, but curious to learn more...</p> <p>The infrautils.ready service is available in Oxygen, and this issue is overly broad and has nothing actionable (that I can see) for Fluorine. I encourage all 13 watchers of this issue who have an interest in infrautils.ready to email infrautils-dev with new requirements, which can lead to more specific fine grained issues than this for possible Improvements in Fluorine (an example of such an extension is <a href="https://jira.opendaylight.org/browse/INFRAUTILS-27" title="Ready API for more fine grained per-bundle notifications" class="issue-link" data-issue-key="INFRAUTILS-27"><del>INFRAUTILS-27</del></a>).</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vorburger" class="user-hover" rel="vorburger">vorburger</a> and any other folks that worked to provide this functionality, THANK YOU!</p> <p>I'm starting <a href="https://git.opendaylight.org/gerrit/c/69575/" class="external-link" target="_blank" rel="nofollow noopener">work </a> to use it in our CSIT jobs so we can just wait for this for-sure (hopefully) utility to tell us<br/> when we are good to go.</p> <p>I'll email infrautils, but I think a feature request I have is to make this information available via REST API.<br/> I know deployment tools out there that can benefit from this. Also other fun things like haproxy.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jluhrsen" class="user-hover" rel="jluhrsen">jluhrsen</a> ready service status is Incorporated in the showSvcStatus Cli output of diagstatus, which you would have seen sathwik incorporating in genius CSIT.. The same status is available as Mbean, which can be accessed over REST..</p> <blockquote><p>Jamo Luhrsen ready service status is Incorporated in the showSvcStatus Cli output of diagstatus, which you would have seen sathwik incorporating in genius CSIT.. The same status is available as Mbean, which can be accessed over REST..</p></blockquote> <p>I do remember seeing a CSIT patch(es) with that showSvcStatus CLI, but didn't think it was related to this "ready status". What is the URI to hit to see this<br/> with REST?</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jluhrsen" class="user-hover" rel="jluhrsen">jluhrsen</a> just create a new JIRA, if still needed <a href="https://lists.opendaylight.org/pipermail/infrautils-dev/2018-March/000631.html" class="external-link" target="_blank" rel="nofollow noopener">following this email thread</a>.</p> <p>This is awesome, thanks <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vorburger" class="user-hover" rel="vorburger">vorburger</a>!</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jluhrsen" class="user-hover" rel="jluhrsen">jluhrsen</a> - Once you have an example of this in CSIT I'd like to copy it in Int/Pack logic.</p> <blockquote><p>This is awesome, thanks Michael Vorburger!</p> <p>Jamo Luhrsen - Once you have an example of this in CSIT I'd like to copy it in Int/Pack logic.</p></blockquote> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=dfarrell07" class="user-hover" rel="dfarrell07">dfarrell07</a> , here is a <a href="https://git.opendaylight.org/gerrit/c/69575/4/jjb/integration/integration-deploy-controller-run-test.sh" class="external-link" target="_blank" rel="nofollow noopener">patch</a> where<br/> I'm grepping the karaf.log for the specific message. I'll figure out the REST way of doing this too and maybe propose that as well.</p> Blocks CONTROLLER-519 DAEXIM-3 INFRAUTILS-17 INFRAUTILS-27 ODLPARENT-86 Duplicate CONTROLLER-519 Development External issue ID 8415 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i01mhz: