[NETCONF-234] support RESTCONF PATCH for mounted NETCONF nodes Created: 26/Jul/16 Updated: 15/Mar/19 Resolved: 11/May/17 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | restconf-nb |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Giles Heron | Assignee: | Ivan Hrasko |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||
| Description |
|
we already have RESTCONF PATCH support (draft-ietf-netconf-yang-patch) for nodes in ODL's data store. Can we please extend that support to mounted NETCONF data stores? I guess the challenge here is that one RESTCONF PATCH will translate to multiple different NETCONF operations within a single transaction? At any rate this is required for real-world operation where you're managing your network using RESTCONF. |
| Comments |
| Comment by Ivan Hrasko [ 02/Sep/16 ] |
|
Gerrit Patch: |
| Comment by Ivan Hrasko [ 09/Sep/16 ] |
|
Some PATCH edit operations do bot work properly on mounted devices due to https://bugs.opendaylight.org/show_bug.cgi?id=6681 |
| Comment by Ivan Hrasko [ 19/Sep/16 ] |
|
Gerrit patch for old restconf is waiting for review: |
| Comment by Ivan Hrasko [ 23/Sep/16 ] |
|
Gerrit patch for new restconf: https://git.opendaylight.org/gerrit/#/c/46123/ |
| Comment by Ivan Hrasko [ 23/Sep/16 ] |
|
To work with transaction chains on mount point s you need: https://git.opendaylight.org/gerrit/#/c/45575/ |
| Comment by Ivan Hrasko [ 06/Oct/16 ] |
|
adaptation for Beryllium: |
| Comment by Giles Heron [ 20/Oct/16 ] |
|
Will this be in Beryllium-SR4 and Boron-SR1? |
| Comment by Jakub Toth [ 21/Oct/16 ] |
|
(In reply to Giles Heron from comment #8) Hi Giles, This is in both releases. Regards, Jakub Toth |
| Comment by Giles Heron [ 21/Oct/16 ] |
|
do you have any examples of using this to edit a mounted resource? |
| Comment by Ivan Hrasko [ 24/Oct/16 ] |
|
See for example: https://lists.opendaylight.org/pipermail/netconf-dev/2016-October/000718.html |
| Comment by Giles Heron [ 24/Oct/16 ] |
|
yup - I saw that. Still wasn't able to make it work might start by trying a non-mounted model |
| Comment by Ivan Hrasko [ 24/Oct/16 ] |
|
Yes, try first non-mounted, mounted is the same, only URi changes. |
| Comment by BABU K T [ 28/Apr/17 ] |
|
I could see below challenges while executing HTTP PATCH on a netconf mount point. Version : Boron 1. Is yang patch not supported to change configuaration datastore on mount point ? ”, but still it is listed under available-capability for mount point and seeing below error while trying to add config in yang-patch format. HTTP PATCH method: PATCH /restconf/config/network-topology:network-topology/topology/topology-netconf/node/device1/yang-ext:mount/ietf-yang-patch:yang-patch HTTP/1.1 Headers: Accept: application/yang.patch-status+xml Body: { } Response: { ] karaf Log: 2017-04-28 14:36:59,488 | WARN | ssing-executor-1 | NetconfDevice | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 2017-04-28 14:36:59,488 | DEBUG | ssing-executor-1 | NetconfDevice | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | {}: Unable to build schema context, unsatisfied imports {}, will reattempt with resolved only SchemaResolutionException{unsatisfiedImports={RevisionSourceIdentifier [name=ietf-ya at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$AssembleSources.apply(SharedSchemaContextFactory.java:203)[62:org.opendayli ght.yangtools.yang-parser-impl:1.0.1.Boron-SR1] at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$AssembleSources.apply(SharedSchemaContextFactory.java:170)[62:org.opendayli ght.yangtools.yang-parser-impl:1.0.1.Boron-SR1] at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:906)[38:com.google.guava:18.0.0] at com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)[38:com.google.guava:18.0.0] at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)[38:com.google.guava:18.0.0] at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)[38:com.google.guava:18.0.0] at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)[38:com.google.guava:18.0.0] at com.google.common.util.concurrent.Futures.transform(Futures.java:567)[38:com.google.guava:18.0.0] at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory.createSchemaContext(SharedSchemaContextFactory.java:104)[62:org.opendayligh t.yangtools.yang-parser-impl:1.0.1.Boron-SR1] at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory.createSchemaContext(SharedSchemaContextFactory.java:72)[62:org.opendaylight .yangtools.yang-parser-impl:1.0.1.Boron-SR1] at org.opendaylight.yangtools.yang.model.repo.api.SchemaContextFactory.createSchemaContext(SchemaContextFactory.java:37)[59:org.opendaylight.yangtool s.yang-model-api:1.0.1.Boron-SR1] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$SchemaSetup.setUpSchema(NetconfDevice.java:451)[263:org.opendaylight.netconf.sal-netcon f-connector:1.4.1.Boron-SR1] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$SchemaSetup.run(NetconfDevice.java:428)[263:org.opendaylight.netconf.sal-netconf-connec tor:1.4.1.Boron-SR1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_121] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121] at java.lang.Thread.run(Thread.java:745)[:1.8.0_121] 2017-04-28 14:36:59,488 | TRACE | ssing-executor-1 | NetconfDevice | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | RemoteDevice{patch} : Trying to build schema context from [RevisionSourceIdentifier [name=show-version@2017-01-01]] 2017-04-28 14:36:59,494 | INFO | ssing-executor-1 | MasterSalFacade | 267 - org.opendaylight.netconf.topology-singleton - 1.1.1.Boron-SR1 | RemoteDevice{patch} : Creating master data broker for device tration@671e331 2017-04-28 14:36:59,497 | DEBUG | ssing-executor-1 | KeepaliveSalFacade | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | RemoteDevice{patch} : Netconf session initiated, starting keepalives 2017-04-28 14:36:59,497 | TRACE | ssing-executor-1 | KeepaliveSalFacade | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | RemoteDevice{patch} : Scheduling next keepalive in 120 SECONDS 2017-04-28 14:36:59,497 | TRACE | dispatcher-58809 | NetconfDeviceTopologyAdapter | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | RemoteDevice{patch} : Update device state transaction DOM-CHAIN-65-1 merging operational data started. 2017-04-28 14:36:59,498 | TRACE | dispatcher-58809 | NetconfDeviceTopologyAdapter | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | RemoteDevice{patch} : Committing Transaction update:DOM-CHAIN-65-1 : Transaction(update) DOM-CHAIN-65-1 SUCCESSFUL ] 2017-04-28 14:37:47,618 | TRACE | ssing-executor-8 | NetconfDeviceCommunicator | 263 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR 1 | RemoteDevice{deploy} : Sending message <rpc message-id="m-285" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> |
| Comment by Ivan Hrasko [ 11/May/17 ] |
|
Hi Yang PATCH is supported on mount points in latest Boron (SR-3). message: { ] wants to tell you that module "ietf-yang-patch" does not exist behind mount point (its different bug solved in next releases: ietf-yang-patch describes Yang PATCH data message structure, it is not located on mount point or controller itself. Regards |
| Comment by Ivan Hrasko [ 11/May/17 ] |
|
See examples: Just change URI to point to your mount point. |