Operating System: Linux
Platform: PC

Update: this behaviour is noticed only using new data-store:

2014-04-17 04:43:41.709 PDT [nettyThreadgroupModule$NioEventLoopGroupCloseable-6-2] TRACE o.o.c.m.s.d.s.i.InMemoryDOMDataStore - Data Tree is data {
.... path {
ero {
processing-rule false
subobject {
subobject[] {
loose false
subobject-type {
ip-prefix

}
}.....

Hello, this is my first bugzilla comment ever.
CONTROLLER-333 was possibly not fixed enough, at least for Restconf RPC with JSON data.
Adding piece of e-mail communication:

From: Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO at Cisco)
Sent: Friday, May 30, 2014 5:03 PM
To: Vratko Polak -X (vrpolak - Pantheon Technologies SRO at Cisco); Ladislav Borak -X (lborak - Pantheon Technologies SRO at Cisco); Jozef Gloncak -X (jgloncak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
Cc: wave_demo_support(mailer list)
Subject: RE: ERO in JSON

Seems related to: https://bugs.opendaylight.org/show_bug.cgi?id=767, except this time it's first ERO, that is visible. Not sure if restconf or data-store issue.
________________________________________
From: Vratko Polak -X (vrpolak - Pantheon Technologies SRO at Cisco)
Sent: Friday, May 30, 2014 4:51 PM
To: Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO at Cisco)
Cc: wave_demo_support(mailer list)
Subject: ERO in JSON
Hi.
I have tried creating curl command using JSON data
that would create tunnel with explicit path.
This is XML data version which works ok:
curl -X POST -H "Content-Type:application/yang.data+xml" -d '<input><node>pcc://39.39.39.39</node><name>odveci</name><network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref><arguments><endpoints-obj><ipv4><source-ipv4-address>39.39.39.39</source-ipv4-address><destination-ipv4-address>43.43.43.43</destination-ipv4-address></ipv4></endpoints-obj><ero><subobject><loose>false</loose><ip-prefix><ip-prefix>195.20.160.40/32</ip-prefix></ip-prefix></subobject><subobject><loose>false</loose><ip-prefix><ip-prefix>201.20.160.43/32</ip-prefix></ip-prefix></subobject><subobject><loose>false</loose><ip-prefix><ip-prefix>43.43.43.43/32</ip-prefix></ip-prefix></subobject></ero></arguments></input>' 127.0.0.1:8080/restconf/operations/network-topology-pcep:add-lsp
and this is JSON version which almost works:
curl -X POST -H "Content-Type:application/yang.data+json" -d '{"input":{"node":"pcc://39.39.39.39","name":"odveci","network-topology-ref":"/network-topology:network-topology/network-topology:topology[network-topology:topology-id=\"pcep-topology\"]","arguments":{"endpoints-obj":{"ipv4":{"source-ipv4-address":"39.39.39.39","destination-ipv4-address":"43.43.43.43"}},"ero":[{"subobject":{"loose":false,"ip-prefix":

}},{"subobject":{"loose":false,"ip-prefix":

}},{"subobject":{"loose":false,"ip-prefix":

}}]}}}' 127.0.0.1:8080/restconf/operations/network-topology-pcep:add-lsp
but in this case created tunnel only has
one of 3 hops, the first one to 195.20.160.40.
Is this a known issue?

Seems to Restconf / Yangtools error, not datastore related.

I tried to do test case with list without keys but for me everything worked OK. I passed through YANG model and in pcep-types.yang I found that grouping explicit-route-object contains
container ero {
...omitted....
list subobject

...omitted...
}

You constructed your CURL for JSON as
"ero": [
{
"subobject":

},
{
"subobject":

},
{
"subobject":

}
]

sorry,
I submitted previous comment by mistake and I couldn't find way how to edit it so I pasted correct syntax for JSON once again

"ero": {
"subobject":[

,

]

I am going to try simulate this case.

I can confirm that I successfully reproduced bug on YANG model
container cont {
container cont1 {
list lst {
leaf lf1

}
}
}

where I constructed incorrect JSON input like
{
"cont":{
"cont1":[
{
"lst":

},
{
"lst":

}
]
}
}

So conclusion is that YANG element has to be mapped to JSON:

• container -> "container_name":{}
• list -> "list_name":[{},{},...{}]

and not vice versa.

Please retest.

After changing JSON data to correct ones, update-lsp works without issues.