<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:09:50 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[MDSAL-447] Support life cycle management of YANG file at runtime</title>
                <link>https://jira.opendaylight.org/browse/MDSAL-447</link>
                <project id="10137" key="MDSAL">mdsal</project>
                    <description>&lt;p&gt;Life cycle management of YANG file can start with add and delete only.&lt;/p&gt;

&lt;p&gt;Here is what I envison:&lt;/p&gt;

&lt;p&gt;Use case would be to have external system able to&lt;/p&gt;

&lt;p&gt;&#160; 1. manage YANG model(s) that are self contained, e.g. there is no interaction with other deployed YANGs&lt;br/&gt;
 &#160;&#160;&#160; - &lt;b&gt;add&lt;/b&gt;:&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160; &lt;em&gt;action&lt;/em&gt;: RPC to either accept a file, or a raw string&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160; &lt;em&gt;behaviour&lt;/em&gt;: That RPC would &lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; validate the YANG file(s)&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; generate RESTCONF APIs to interact with it&lt;br/&gt;
 &#160;&#160;&#160; - &lt;b&gt;delete&lt;/b&gt;&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160; &lt;em&gt;action&lt;/em&gt;: RPC to delete based on module name and revision date (assuming this combinaison is unique)&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160; &lt;em&gt;behaviour&lt;/em&gt;: That RPC would &lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; delete the datastore owned by that YANG (config and oper)&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; unsubscribe all open web-socket subscribtion(s) to any path of that YANG tree&lt;br/&gt;
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; unsubscribe all open YANG notification subscriptions&lt;br/&gt;
 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; remove the generated RESTCONF APIs along with the YANG file(s)&lt;/p&gt;

&lt;p&gt;&#160; 2. Interact with specific YANG tree using the generated RESTCONF APIs of that YANG, for config and/or oper based on use case&lt;/p&gt;

&lt;p&gt;&#160; 3. Register to web-socket notification for a specific path/sub-path of a YANG, or use TSDR for consumption of YANG notification (e.g. through kafka)&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;The web-socket / YANG notification thing can be seen as enhancements.&lt;/p&gt;</description>
                <environment></environment>
        <key id="31663">MDSAL-447</key>
            <summary>Support life cycle management of YANG file at runtime</summary>
                <type id="10000" iconUrl="https://jira.opendaylight.org/images/icons/issuetypes/epic.svg">Epic</type>
                                            <priority id="4" iconUrl="https://jira.opendaylight.org/images/icons/priorities/minor.svg">Low</priority>
                        <status id="10003" iconUrl="https://jira.opendaylight.org/images/icons/status_generic.gif" description="">Confirmed</status>
                    <statusCategory id="2" key="new" colorName="blue-gray"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="adetalhouet">Alexis de Talhou&#235;t</reporter>
                        <labels>
                    </labels>
                <created>Mon, 6 May 2019 20:39:16 +0000</created>
                <updated>Tue, 25 Jun 2019 20:03:09 +0000</updated>
                                                                                <due></due>
                            <votes>0</votes>
                                    <watches>2</watches>
                                                                                                                <comments>
                            <comment id="66859" author="rovarga" created="Sat, 8 Jun 2019 00:59:12 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=adetalhouet&quot; class=&quot;user-hover&quot; rel=&quot;adetalhouet&quot;&gt;adetalhouet&lt;/a&gt; do I understand correctly 3. to mean that effectively you&apos;d like to see a stream of updates to a particular Kafka topic being delivered whenever a YangInstanceIdentifier changes?&lt;/p&gt;</comment>
                            <comment id="66927" author="adetalhouet" created="Tue, 25 Jun 2019 10:58:26 +0000"  >&lt;p&gt;Yes, but this is, at this point, the least important part of the feature.&lt;/p&gt;

&lt;p&gt;The key of this really to have the ability to load yang in the system at runtime&#160; and have restconf binding auto-generated with APIs for that yang being exposed.&lt;/p&gt;</comment>
                            <comment id="66929" author="rovarga" created="Tue, 25 Jun 2019 15:18:28 +0000"  >&lt;p&gt;Yes, so essentially you would be using this as a REST-accessible external datastore to some other system, right?&lt;/p&gt;</comment>
                            <comment id="66931" author="adetalhouet" created="Tue, 25 Jun 2019 15:24:41 +0000"  >&lt;p&gt;Yes, exactly.&lt;/p&gt;</comment>
                            <comment id="66932" author="rovarga" created="Tue, 25 Jun 2019 15:32:15 +0000"  >&lt;p&gt;Right. So I think we do have all the building blocks needed, it&apos;s just a matter of some quality LEGO time.&lt;/p&gt;</comment>
                            <comment id="66933" author="adetalhouet" created="Tue, 25 Jun 2019 15:38:36 +0000"  >&lt;p&gt;That&apos;s what I think as well. I&apos;ll be glad to help assembling LEGO if needed. If you have pointers/ideas on how to do, I can work on it.&lt;/p&gt;

&lt;p&gt;Thank you for considering the feature, I believe this will be a great addition to ODL.&lt;/p&gt;</comment>
                            <comment id="66934" author="rovarga" created="Tue, 25 Jun 2019 15:45:55 +0000"  >&lt;p&gt;Changed to epic, as this really is a project-scoped thing, i.e. it has a RESTCONF dependency, but it&apos;s not something we want to co-install with other features except our dependencies.&lt;/p&gt;

&lt;p&gt;One thing to consider: should the management (add/remove models) and access (get/put) have different endpoints?&lt;/p&gt;</comment>
                            <comment id="66936" author="adetalhouet" created="Tue, 25 Jun 2019 16:51:05 +0000"  >&lt;p&gt;&amp;gt; this really is a project-scoped thing&lt;/p&gt;

&lt;p&gt;Right, I was initially thinking MDSAL providing this feature, but I don&apos;t know if MDSAL could have dependency on RESTCONF, given the dependency tree. But with these projects having their own release lifecycle, maybe it is acceptable..&lt;/p&gt;

&lt;p&gt;&amp;gt; One thing to consider: should the management (add/remove models) and access (get/put) have different endpoints?&lt;/p&gt;

&lt;p&gt;Yes, I envision management API/contract having its own model, defining a container having a list with revision-date and namespace as keys. That model could have RPCs for add/remove models, but this could be redundant with get/put to the list.&lt;/p&gt;

&lt;p&gt;For data access, I was thinking of using RESTCONF RFC standard following the same pattern as other YANGs already exposed by ODL.&lt;/p&gt;</comment>
                            <comment id="66937" author="rovarga" created="Tue, 25 Jun 2019 17:07:50 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=adetalhouet&quot; class=&quot;user-hover&quot; rel=&quot;adetalhouet&quot;&gt;adetalhouet&lt;/a&gt; so on the datastore semantics: do you just need running (implied stored), or running without persistence, or also operational?&lt;/p&gt;

&lt;p&gt;In NMDA-speak:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;do you need to manipulate &apos;intended&apos;?&lt;/li&gt;
	&lt;li&gt;if so, is &apos;intended&apos; all you care about?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="66938" author="adetalhouet" created="Tue, 25 Jun 2019 18:28:13 +0000"  >&lt;p&gt;I was thinking having configuration and operational datastores, so the external system can track state accordingly.&lt;/p&gt;

&lt;p&gt;I&apos;m not familiar with the NMDA terminology, but it seems&lt;br/&gt;
The intended configuration datastore (&amp;lt;intended&amp;gt;) is a read-only configuration datastore&lt;br/&gt;
hence I&apos;m not sure that is the expectation, as the point would be to have external system able to write to the datastore.&lt;/p&gt;</comment>
                            <comment id="66939" author="rovarga" created="Tue, 25 Jun 2019 19:08:19 +0000"  >&lt;p&gt;Not only that, &amp;lt;intended&amp;gt; is not persisted and derived from &amp;lt;running&amp;gt; plus-whatever-implementation-specific.&lt;/p&gt;

&lt;p&gt;At any rate, if you are looking for operational, you are in violation of RFC8040 (which boils down to running-only), so you need NMDA as well.&lt;/p&gt;

&lt;p&gt;That opens up a bit of a question: to what extent do you need the validated? Should we go for &apos;config=true, paranoid&apos; or are there things we can rely on the user to do?&lt;/p&gt;</comment>
                            <comment id="66940" author="rovarga" created="Tue, 25 Jun 2019 19:09:26 +0000"  >&lt;p&gt;Forgot to explicitly call out: do you expect persistence guarantees? (assuming here that you&apos;d run a container-per-datastore model here)&lt;/p&gt;</comment>
                            <comment id="66941" author="adetalhouet" created="Tue, 25 Jun 2019 20:03:09 +0000"  >&lt;p&gt;I&apos;m not familiar with these things. Basically, datastore semantics doesn&apos;t need to be anything different than what ODL has to offer today. Likewise for the persistence, as there are already mechanisms to backup&amp;amp;restore and persist datastore today.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i03nov:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>