EDIT-CONFIG Replace vs Merge question

[Brian Rushka]

REF: git branch 0.6.0

With a modified toaster.yin (see attachments) and the example netconf-client I execute:

   netconf> edit-config --defop replace --test test-then-set --config /home/me/xmlscripts/test-b.xml running
      Result OK

Then with the same config file I attempt a MERGE:

   netconf> edit-config --defop merge --test test-then-set --config /home/me/xmlscripts/test-b.xml running
   NETCONF error: unknown-element (application) - An unexpected element is present.

QUESTION: Do I not understand NETCONF MERGE?

I believe the merge operation should accept changes to any or all of the config within the referenced node and preserve any missing subset.
In this case, config script test-a.xml contains all of the fields within a container and test-b.xml contains a subset of fields, changing two.
When applied with REPLACE, the operation succeeds. When applied with MERGE the operation fails.

-Brian

[Radek Krejčí]

Hi Brian,
hmm, three things:

1) If I see the model correctly, it defines this:

<toaster xmlns="http://netconfcentral.org/ns/toaster">
</toaster>
<test xmlns="http://netconfcentral.org/ns/toaster">
</test>

not this:
<toaster xmlns="http://netconfcentral.org/ns/toaster">
<test/>
</toaster>

And I would really recommend the second one, there is some IETF
recommendation to have only one "root" container in a single YANG module

2) Then it is strange that replace succeeds and merge not - can you send
me a content of the running datastore before and after that requests?

3) please use command 'debug' in the client and send me the complete
content of the rpc-reply with rpc-error

Best regards,
Radek

Dne 28.9.2013 05:23, Brian Rushka napsal(a):

> REF: git branch 0.6.0
>
> With a modified toaster.yin (see attachments) and the example
> netconf-client I execute:
>

> / netconf> edit-config --defop *replace* --test test-then-set --config
> /home/me/xmlscripts/test-b.xml running/

> Result OK
>
> Then with the same config file I attempt a MERGE:
>

> / netconf> edit-config --defop *merge* --test test-then-set --config
> /home/me/xmlscripts/test-b.xml running/

> NETCONF error: unknown-element (application) - An unexpected element
> is present.
>
> QUESTION: Do I not understand NETCONF MERGE?
>
> I believe the merge operation should accept changes to any or all of the
> config within the referenced node and preserve any missing subset.
> In this case, config script test-a.xml contains all of the fields within
> a container and test-b.xml contains a subset of fields, changing two.
> When applied with REPLACE, the operation succeeds. When applied with
> MERGE the operation fails.
>
> -Brian
>

> --
> You received this message because you are subscribed to the Google
> Groups "libnetconf" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libnetconf+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/libnetconf.

[Brian Rushka]

Hi Radek,
Please see responses inline.
-Brian

On Friday, September 27, 2013 11:50:21 PM UTC-7, Radek Krejčí wrote:

Hi Brian,
hmm, three things:

1) If I see the model correctly, it defines this:

<toaster xmlns="http://netconfcentral.org/ns/toaster">
</toaster>
<test xmlns="http://netconfcentral.org/ns/toaster">
</test>

not this:
<toaster xmlns="http://netconfcentral.org/ns/toaster">
    <test/>
</toaster>

And I would really recommend the second one, there is some IETF
recommendation to have only one "root" container in a single YANG module

I will alter the YANG and try again.
 

2) Then it is strange that replace succeeds and merge not - can you send
me a content of the running datastore before and after that requests?

I've attached the datastore.xml before and after the "edit-config replace" request.

3) please use command 'debug' in the client and send me the complete
content of the rpc-reply with rpc-error

Client console debug output is attached as console-debug.txt

[Radek Krejčí]

Hi Brian,
thanks for info. I have tested that on current master as well as on
0.6.x branch, but I'm getting different results. For me, the results for
merge and replace are the same - it doesn't pass the validation.

Now, I suppose that the test element was moved into the toaster element
as I mentioned in previous mail.

There is only <toaster><test><L> container defined in data model, but
you send config data with <toaster><test><C> and <toaster><test><R>
containers. When I removed these two containers from edit-config's data,
the result was OK.

Please also check, that you are using validators (generated by lnctool)
that reflects your changes to the model. The validators files should be
placed in the same directory as yin model passed to the ncds_new* function.

Please let me know, if correction of model/edit-config data will help.
I'm enclosing the data model that I used for my tests.

Best regards,
Radek

Dne 30.9.2013 21:16, Brian Rushka napsal(a):

[Brian Rushka]

Hi Radek,

Thank you for following up.

Apparently, I do not yet understand the proper workflow.

Can I use the lnctool on the client side? I need suggestions on how to generate correct edit-config XML strings. Initially, I can hard code the messages, but as our device data model evolves I will need to create messages to access subsets of the configuration.

At this point, I believe a partial configuration change means either:
1. edit a full schema on the client side and send a complete configuration, or
2. isolate the target part of the schema and send a partial update that the server can understand.

Best regards,
Brian

-----Original Message-----
From: Radek Krejčí [mailto:rkr...@cesnet.cz]
Sent: Thursday, October 03, 2013 12:22 AM
To: Brian Rushka
Cc: libne...@googlegroups.com
Subject: Re: [libnetconf] EDIT-CONFIG Replace vs Merge question

Hi Brian,
thanks for info. I have tested that on current master as well as on 0.6.x branch, but I'm getting different results. For me, the results for merge and replace are the same - it doesn't pass the validation.

Now, I suppose that the test element was moved into the toaster element as I mentioned in previous mail.

There is only <toaster><test><L> container defined in data model, but you send config data with <toaster><test><C> and <toaster><test><R> containers. When I removed these two containers from edit-config's data, the result was OK.

Please also check, that you are using validators (generated by lnctool) that reflects your changes to the model. The validators files should be placed in the same directory as yin model passed to the ncds_new* function.

Please let me know, if correction of model/edit-config data will help.
I'm enclosing the data model that I used for my tests.

Best regards,
Radek

Important: This e-mail is only meant for the intended recipient of the transmission, and may be a confidential communication or a communication privileged by law. If you received this e-mail in error, any review, use, dissemination, distribution, or copying of this e-mail is strictly prohibited. Please notify us immediately of the error by return e-mail and please delete this message from each computer or server on which it is stored (without copying it or printing it out) and take no other action based on its content. Thank you in advance for your cooperation.

[Radek Krejčí]

Hi Brian,

Dne 3.10.2013 20:53, Brian Rushka napsal(a):

> Hi Radek,
>
> Thank you for following up.
>

no problem

> Apparently, I do not yet understand the proper workflow.
>
> Can I use the lnctool on the client side? I need suggestions on how to generate correct edit-config XML strings. Initially, I can hard code the messages, but as our device data model evolves I will need to create messages to access subsets of the configuration.
>

lnctool is supposed only for the server side - from the YANG file it
generates yin format (used by libnetconf instead of yang) and files
(schemas and stylesheets) for validation.

Preparing NETCONF requests (especially edit-config's) content is
currently out of scope of the Netopeer tools (and libnetconf as well).
We are preparing Netopeer WebGUI which, based on YANG data model
provided by the server via get-schema operation (some RFC, I don't
remember the number right now), creates Web interface and then generates
edit-config's content automatically based on user's changes of the
configuration data in the user interface. WebGUI will be published as
part of the Netopeer project in a month or two.

Creating edit-config's XML that modifies configuration data is out of
libnetconf scope and the creation of such data is up to the specific client.

> At this point, I believe a partial configuration change means either:
> 1. edit a full schema on the client side and send a complete configuration, or
> 2. isolate the target part of the schema and send a partial update that the server can understand.
>

yes, actually 1. is usually copy-config and the 2. is edit-config, but
there is no limitation to use edit-config for the 1. And libnetconf
supports this, but preparation of the configuration data is up to the
client.

Best regards,
Radek