<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 19:54:58 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>[CONTROLLER-1217] Clustering : unable to configure persistence using restconf(netconf connector) on 3 node cluster</title>
                <link>https://jira.opendaylight.org/browse/CONTROLLER-1217</link>
                <project id="10113" key="CONTROLLER">controller</project>
                    <description>&lt;p&gt;odl: &lt;a href=&quot;https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.3.0-SNAPSHOT/distribution-karaf-0.3.0-20150317.094607-668.tar.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.3.0-SNAPSHOT/distribution-karaf-0.3.0-20150317.094607-668.tar.gz&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;installed features: odl-restconf odl-mdsal-clustering odl-restconf-all odl-openflowplugin-all odl-netconf-connector-all&lt;br/&gt;
installed bundles: mvn:org.jolokia/jolokia-osgi/1.1.5&lt;/p&gt;

&lt;p&gt;-Xms128M -Xmx2048m -XX:MaxPermSize=512m &lt;/p&gt;

&lt;p&gt;VM: fedora18, 6G ram, &lt;br/&gt;
java -version&lt;br/&gt;
java version &quot;1.7.0_67&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)&lt;/p&gt;


&lt;p&gt;i have installed 3 node cluster with config datastore shart persistence=false.&lt;br/&gt;
i wanted to switch it on (persistence=true) using restconf and postman&lt;/p&gt;

&lt;p&gt;method: POST&lt;/p&gt;

&lt;p&gt;url:&lt;a href=&quot;http://g37:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://g37:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;data:&lt;br/&gt;
&amp;lt;modules xmlns=&quot;urn:opendaylight:params:xml:ns:yang:controller:config&quot;&amp;gt;&lt;br/&gt;
&amp;lt;module xmlns=&quot;urn:opendaylight:params:xml:ns:yang:controller:config&quot;&amp;gt;&lt;br/&gt;
    &amp;lt;type &lt;br/&gt;
        xmlns:x=&quot;urn:opendaylight:params:xml:ns:yang:controller:config:distributed-datastore-provider&quot;&amp;gt;x:distributed-config-datastore-provider&lt;br/&gt;
    &amp;lt;/type&amp;gt;&lt;br/&gt;
    &amp;lt;name&amp;gt;distributed-config-store-module&amp;lt;/name&amp;gt;&lt;br/&gt;
    &amp;lt;config-properties &lt;br/&gt;
        xmlns=&quot;urn:opendaylight:params:xml:ns:yang:controller:config:distributed-datastore-provider&quot;&amp;gt;&lt;br/&gt;
        &amp;lt;shard-transaction-idle-timeout-in-minutes&amp;gt;10&amp;lt;/shard-transaction-idle-timeout-in-minutes&amp;gt;&lt;br/&gt;
        &amp;lt;shard-journal-recovery-log-batch-size&amp;gt;5000&amp;lt;/shard-journal-recovery-log-batch-size&amp;gt;&lt;br/&gt;
        &amp;lt;persistent&amp;gt;true&amp;lt;/persistent&amp;gt;&lt;br/&gt;
        &amp;lt;operation-timeout-in-seconds&amp;gt;5&amp;lt;/operation-timeout-in-seconds&amp;gt;&lt;br/&gt;
        &amp;lt;shard-transaction-commit-timeout-in-seconds&amp;gt;30&amp;lt;/shard-transaction-commit-timeout-in-seconds&amp;gt;&lt;br/&gt;
        &amp;lt;shard-election-timeout-factor&amp;gt;2&amp;lt;/shard-election-timeout-factor&amp;gt;&lt;br/&gt;
        &amp;lt;shard-initialization-timeout-in-seconds&amp;gt;300&amp;lt;/shard-initialization-timeout-in-seconds&amp;gt;&lt;br/&gt;
        &amp;lt;enable-metric-capture&amp;gt;false&amp;lt;/enable-metric-capture&amp;gt;&lt;br/&gt;
        &amp;lt;transaction-creation-initial-rate-limit&amp;gt;100&amp;lt;/transaction-creation-initial-rate-limit&amp;gt;&lt;br/&gt;
        &amp;lt;shard-snapshot-data-threshold-percentage&amp;gt;12&amp;lt;/shard-snapshot-data-threshold-percentage&amp;gt;&lt;br/&gt;
        &amp;lt;shard-heartbeat-interval-in-millis&amp;gt;500&amp;lt;/shard-heartbeat-interval-in-millis&amp;gt;&lt;br/&gt;
        &amp;lt;bounded-mailbox-capacity&amp;gt;1000&amp;lt;/bounded-mailbox-capacity&amp;gt;&lt;br/&gt;
        &amp;lt;shard-leader-election-timeout-in-seconds&amp;gt;30&amp;lt;/shard-leader-election-timeout-in-seconds&amp;gt;&lt;br/&gt;
        &amp;lt;max-shard-data-change-executor-queue-size&amp;gt;1000&amp;lt;/max-shard-data-change-executor-queue-size&amp;gt;&lt;br/&gt;
        &amp;lt;max-shard-data-change-executor-pool-size&amp;gt;20&amp;lt;/max-shard-data-change-executor-pool-size&amp;gt;&lt;br/&gt;
        &amp;lt;shard-isolated-leader-check-interval-in-millis&amp;gt;5000&amp;lt;/shard-isolated-leader-check-interval-in-millis&amp;gt;&lt;br/&gt;
        &amp;lt;max-shard-data-store-executor-queue-size&amp;gt;5000&amp;lt;/max-shard-data-store-executor-queue-size&amp;gt;&lt;br/&gt;
        &amp;lt;shard-snapshot-batch-count&amp;gt;20000&amp;lt;/shard-snapshot-batch-count&amp;gt;&lt;br/&gt;
        &amp;lt;shard-batched-modification-count&amp;gt;100&amp;lt;/shard-batched-modification-count&amp;gt;&lt;br/&gt;
        &amp;lt;max-shard-data-change-listener-queue-size&amp;gt;1000&amp;lt;/max-shard-data-change-listener-queue-size&amp;gt;&lt;br/&gt;
        &amp;lt;shard-transaction-commit-queue-capacity&amp;gt;20000&amp;lt;/shard-transaction-commit-queue-capacity&amp;gt;&lt;br/&gt;
    &amp;lt;/config-properties&amp;gt;&lt;br/&gt;
    &amp;lt;config-schema-service &lt;br/&gt;
        xmlns=&quot;urn:opendaylight:params:xml:ns:yang:controller:config:distributed-datastore-provider&quot;&amp;gt;&lt;br/&gt;
        &amp;lt;name&amp;gt;yang-schema-service&amp;lt;/name&amp;gt;&lt;br/&gt;
        &amp;lt;type &lt;br/&gt;
            xmlns:x=&quot;urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom&quot;&amp;gt;x:schema-service&lt;br/&gt;
        &amp;lt;/type&amp;gt;&lt;br/&gt;
    &amp;lt;/config-schema-service&amp;gt;&lt;br/&gt;
&amp;lt;/module&amp;gt;&lt;br/&gt;
  &amp;lt;/modules&amp;gt;&lt;/p&gt;

&lt;p&gt;headers: accept and content-type to application/xml&lt;/p&gt;

&lt;p&gt;I got 204 but using GET i always see persistence to be false. In the log lots ex exceptions appeared.&lt;/p&gt;

&lt;p&gt;I expected to be able to put data to /restconf/config.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Linux&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
        <key id="25771">CONTROLLER-1217</key>
            <summary>Clustering : unable to configure persistence using restconf(netconf connector) on 3 node cluster</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10001">Won&apos;t Do</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="pgubka@cisco.com">Peter Gubka</reporter>
                        <labels>
                    </labels>
                <created>Tue, 17 Mar 2015 15:05:26 +0000</created>
                <updated>Tue, 25 Jul 2023 08:23:57 +0000</updated>
                            <resolved>Mon, 28 Dec 2015 22:16:26 +0000</resolved>
                                                                    <component>clustering</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>2</watches>
                                                                                                                <comments>
                            <comment id="50294" author="pgubka@cisco.com" created="Tue, 17 Mar 2015 15:05:26 +0000"  >&lt;p&gt;Attachment karaf.log has been added with description: karaf.log&lt;/p&gt;</comment>
                            <comment id="50295" author="pgubka@cisco.com" created="Tue, 17 Mar 2015 15:06:09 +0000"  >&lt;p&gt;Attachment persistent_change_steps.txt has been added with description: steps with console output&lt;/p&gt;</comment>
                            <comment id="50289" author="tpantelis" created="Thu, 9 Apr 2015 14:12:41 +0000"  >&lt;p&gt;I tried the repro steps and it does save the new config to etc/opendaylight/current/controller.currentconfig.xml and it stops the clustered config data store but it appears to fail to restart it as I no longer see the mbean in JConsole. A lot of exceptions occur in the log related to other modules. Restarting the the clustered config data store module will (attempt to) restart modules dependent on it. &lt;/p&gt;

&lt;p&gt;I am not able to read back the configs via restconf due to &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1241&quot; title=&quot;ClassCastException when querying - controller-config/yang-ext:mount/config:modules&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1241&quot;&gt;&lt;del&gt;CONTROLLER-1241&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;I restarted karaf and the clustered config data store starts up fine but doesn&apos;t have the updated config (the config is reported in a JXM bean).&lt;/p&gt;

&lt;p&gt;So this is an issue with the config system.&lt;/p&gt;

&lt;p&gt;Frankly, I don&apos;t recommend updating the clustering config via restconf. It will restart most modules which is basically a crap-shoot as app modules may not handling shutdown/restart properly. Also the entire config for all modules is copied to controller.currentconfig.xml, even if you just changed one. This can break upgrades (assuming the config system properly obtains the configs from controller.currentconfig.xml as intended).&lt;/p&gt;

&lt;p&gt;For these and other reasons, we now have an etc/org.opendaylight.controller.cluster.datastore.cfg properties file that users can modify which is overlayed on top of the config xml settings. We also dynamically react to changes without restarting the clustering modules.&lt;/p&gt;</comment>
                            <comment id="50290" author="tpantelis" created="Thu, 9 Apr 2015 14:17:31 +0000"  >&lt;p&gt;I just noticed that while the clustered config data store started up after karaf restart, the clustered operational data store did not (again lots of exceptions config system).&lt;/p&gt;</comment>
                            <comment id="50291" author="pgubka@cisco.com" created="Thu, 9 Apr 2015 14:31:12 +0000"  >&lt;p&gt;(In reply to Tom Pantelis from comment #2)&lt;br/&gt;
&amp;gt; I tried the repro steps and it does save the new config to&lt;br/&gt;
&amp;gt; etc/opendaylight/current/controller.currentconfig.xml and it stops the&lt;br/&gt;
&amp;gt; clustered config data store but it appears to fail to restart it as I no&lt;br/&gt;
&amp;gt; longer see the mbean in JConsole. A lot of exceptions occur in the log&lt;br/&gt;
&amp;gt; related to other modules. Restarting the the clustered config data store&lt;br/&gt;
&amp;gt; module will (attempt to) restart modules dependent on it. &lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I am not able to read back the configs via restconf due to &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1241&quot; title=&quot;ClassCastException when querying - controller-config/yang-ext:mount/config:modules&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1241&quot;&gt;&lt;del&gt;CONTROLLER-1241&lt;/del&gt;&lt;/a&gt;.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I restarted karaf and the clustered config data store starts up fine but&lt;br/&gt;
&amp;gt; doesn&apos;t have the updated config (the config is reported in a JXM bean).&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; So this is an issue with the config system.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Frankly, I don&apos;t recommend updating the clustering config via restconf. It&lt;br/&gt;
&amp;gt; will restart most modules which is basically a crap-shoot as app modules may&lt;br/&gt;
&amp;gt; not handling shutdown/restart properly. Also the entire config for all&lt;br/&gt;
&amp;gt; modules is copied to controller.currentconfig.xml, even if you just changed&lt;br/&gt;
&amp;gt; one. This can break upgrades (assuming the config system properly obtains&lt;br/&gt;
&amp;gt; the configs from controller.currentconfig.xml as intended).&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; For these and other reasons, we now have an&lt;br/&gt;
&amp;gt; etc/org.opendaylight.controller.cluster.datastore.cfg properties file that&lt;br/&gt;
&amp;gt; users can modify which is overlayed on top of the config xml settings. We&lt;br/&gt;
&amp;gt; also dynamically react to changes without restarting the clustering modules.&lt;/p&gt;

&lt;p&gt;I understand that it is not recommended to change clustering config, but once it is possible, there will always be someone, who just tries it.&lt;/p&gt;</comment>
                            <comment id="50292" author="tpantelis" created="Thu, 9 Apr 2015 14:58:12 +0000"  >&lt;p&gt;Yes - people can try it, assuming one knows how to do it &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;My point is that even if the config system handles on-the-fly restarts properly, all apps have to handle it properly as well. That&apos;s a tall order - it&apos;s not something that people generally test and it will always be a moving target.&lt;/p&gt;

&lt;p&gt;A more fundamental issue is that the entire config for all modules is copied to controller.currentconfig.xml when one module is changed via restconf. That is a significant flaw that can affect upgrades coupled with the fact that internal code wiring config is combined with user-facing config (they can be separated but apps don&apos;t do it). IMO, the config system needs to be re-thought/re-designed wrt user-facing config.&lt;/p&gt;</comment>
                            <comment id="50293" author="moraja@cisco.com" created="Fri, 10 Apr 2015 16:32:22 +0000"  >&lt;p&gt;Moving this to Beryllium for now. I think we can safely assuming people will not be changing configuration for datastore this was in Lithium.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="13495" name="karaf.log" size="92204" author="pgubka@cisco.com" created="Tue, 17 Mar 2015 15:05:26 +0000"/>
                            <attachment id="13496" name="persistent_change_steps.txt" size="14023" author="pgubka@cisco.com" created="Tue, 17 Mar 2015 15:06:09 +0000"/>
                    </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_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2858</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=2858]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Bug]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10204" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>ODL SR Target Milestone</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10349"><![CDATA[Unspecified]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i02p7j:</customfieldvalue>

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