Re: [controller-dev] [netconf-dev] simple RPC question around all optional parameters

2017-08-02 Thread Alexis de Talhouët 
Correct, for instance, when calling ietf-netconf:commit, I use

curl -X POST \
  
http://localhost:8181/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/NODE/yang-ext:mount/ietf-netconf:commit
 \
  -H 'accept: application/json' \
  -H 'authorization: Basic YWRtaW46YWRtaW4=' \
  -H 'content-type: application/xml' \
  -d '

‘
This is due to the way RPC in working in ODL. Adding controller-dev as some 
expert of RPC might provide a good explanation of the why the input is required,
even though nothing is in there.

Regards,
Alexis

> On Aug 2, 2017, at 10:44 AM, Allan Clarke  wrote:
> 
> If you call an RPC that has all optional arguments with a payload like below, 
> then your RPC gets invoked.
>  
> { “input”: { } }
>  
> If you call that RPC with an empty payload, you get an IllegalStateException. 
> I believe this behavior is as intended, meaning that invoking RPCs with 
> nothing is not allowed.
>  
> Can anyone confirm this point-of-view?
>  
> Many Thanks,
>  
> Allan
> ___
> netconf-dev mailing list
> netconf-...@lists.opendaylight.org 
> https://lists.opendaylight.org/mailman/listinfo/netconf-dev 
> 

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] eventTime is missing in the generated notification object

2017-07-27 Thread Alexis de Talhouët 

> On Jul 27, 2017, at 2:22 PM, Robert Varga <n...@hq.sk> wrote:
> 
> On 27/07/17 13:52, Senthil Jayakumar wrote:
>> Hi Alexis et all,
> 
> Hello,
> 
>> 
>> Gentle Reminder!
>> 
>> Any input in this regard is very much appreciated.
> 
> Can you file an issue in bugzilla with those two attachments for
> tracking, please?
> 

Robert, could this be a binding bug where the eventTime equivalent isn’t 
generated in the java POJO?

> Thanks,
> Robert
> 
>> 
>> Thanks
>> Senthil Kumar Jayakumar
>> 
>> On Wed, Jul 19, 2017 at 12:41 PM, Senthil Jayakumar
>> <senthil2commun...@gmail.com <mailto:senthil2commun...@gmail.com>> wrote:
>> 
>>Hi Alexis,
>> 
>>We are using BORON-SR3 and please find the log with the TRACE level
>>enabled and the generated class file attached.
>> 
>>The received notification (both Alarm and event) has the 
>>but the generated notification listener doesn't seem to have
>>reference to the eventTime leaf attribute.
>> 
>>Thanks,
>>Senthil Kumar Jayakumar
>> 
>> 
>> 
>> 
>> 
>> 
>>On Tue, Jul 18, 2017 at 10:37 PM, Alexis de Talhouët
>><adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>> wrote:
>> 
>>Can you provide logs at TRACE level for NETCONF (log:set TRACE
>>org.opendaylight.netconf) and version of ODL in use?
>> 
>>>On Jul 18, 2017, at 8:08 AM, Senthil Jayakumar
>>><senthil2commun...@gmail.com
>>><mailto:senthil2commun...@gmail.com>> wrote:
>>> 
>>>Hi All,
>>> 
>>>Could someone please respond as this is a blocker for us to
>>>proceed further.
>>> 
>>>Thanks,
>>>Senthil Kumar Jayakumar
>>> 
>>>On Fri, Jul 14, 2017 at 4:56 PM, Senthil
>>>Jayakumar <senthil2commun...@gmail.com
>>><mailto:senthil2commun...@gmail.com>> wrote:
>>> 
>>>Hi There,
>>> 
>>>I have found that the eventTime is missing in the
>>>generated NETCONF notification object.
>>> 
>>>Could someone help me how to get the eventTime as part of
>>>the notification object? Without the eventTime the north
>>>bound system is having trouble when a particular event has
>>>occurred.
>>> 
>>>Any help in this regard is appreciated.
>>> 
>>>Thanks,
>>>Senthil Kumar Jayakumar
>>> 
>>> 
>>> 
>>>___
>>>controller-dev mailing list
>>>controller-dev@lists.opendaylight.org
>>><mailto:controller-dev@lists.opendaylight.org>
>>>https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>><https://lists.opendaylight.org/mailman/listinfo/controller-dev>
>> 
>> 
>> 
>> 
>> 
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>> 
> 

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] eventTime is missing in the generated notification object

2017-07-27 Thread Alexis de Talhouët 

> On Jul 27, 2017, at 7:52 AM, Senthil Jayakumar <senthil2commun...@gmail.com> 
> wrote:
> 
> Hi Alexis et all,
> 
> Gentle Reminder!
> 
> Any input in this regard is very much appreciated.

I don’t know if this is a bug or not, but I agree that the evenTime is not 
present in the generated POJO. I tend to think it’s by design, hence this could 
be an enhancement request, or a bug in the binding spec? NETCONF/YangTools 
committers will certainly have more valuable input than mine.
Here is the portion of the code parsing the received xml anyway: 
https://github.com/opendaylight/netconf/blob/d3961ec78d49d5f2df14380e46cbb528ad78d3b9/netconf/sal-netconf-connector/src/main/java/org/opendaylight/netconf/sal/connect/netconf/schema/mapping/NetconfMessageTransformer.java#L89-L123
 
<https://github.com/opendaylight/netconf/blob/d3961ec78d49d5f2df14380e46cbb528ad78d3b9/netconf/sal-netconf-connector/src/main/java/org/opendaylight/netconf/sal/connect/netconf/schema/mapping/NetconfMessageTransformer.java#L89-L123>


> 
> Thanks
> Senthil Kumar Jayakumar
> 
> On Wed, Jul 19, 2017 at 12:41 PM, Senthil Jayakumar 
> <senthil2commun...@gmail.com <mailto:senthil2commun...@gmail.com>> wrote:
> Hi Alexis,
> 
> We are using BORON-SR3 and please find the log with the TRACE level enabled 
> and the generated class file attached.
> 
> The received notification (both Alarm and event) has the  but the 
> generated notification listener doesn't seem to have reference to the 
> eventTime leaf attribute.
> 
> Thanks,
> Senthil Kumar Jayakumar
> 
> 
> 
> 
> 
> 
> On Tue, Jul 18, 2017 at 10:37 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
> Can you provide logs at TRACE level for NETCONF (log:set TRACE 
> org.opendaylight.netconf) and version of ODL in use?
> 
>> On Jul 18, 2017, at 8:08 AM, Senthil Jayakumar <senthil2commun...@gmail.com 
>> <mailto:senthil2commun...@gmail.com>> wrote:
>> 
>> Hi All,
>> 
>> Could someone please respond as this is a blocker for us to proceed further.
>> 
>> Thanks,
>> Senthil Kumar Jayakumar
>> 
>> On Fri, Jul 14, 2017 at 4:56 PM, Senthil Jayakumar 
>> <senthil2commun...@gmail.com <mailto:senthil2commun...@gmail.com>> wrote:
>> Hi There,
>> 
>> I have found that the eventTime is missing in the generated NETCONF 
>> notification object.
>> 
>> Could someone help me how to get the eventTime as part of the notification 
>> object? Without the eventTime the north bound system is having trouble when 
>> a particular event has occurred.
>> 
>> Any help in this regard is appreciated.
>> 
>> Thanks,
>> Senthil Kumar Jayakumar
>> 
>> 
>> 
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org 
>> <mailto:controller-dev@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev 
>> <https://lists.opendaylight.org/mailman/listinfo/controller-dev>
> 
> 

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netconf-dev] issues when mounting junos 17.2 in ODL

2017-07-10 Thread Alexis de Talhouët 
Le lundi 10 juillet 2017, Michael Vorburger  a écrit :

> On Mon, Jul 10, 2017 at 12:53 PM, Abdelmuhaimen Seaudi  > wrote:
>
>> Hi,
>>
>> When I try to mount Junos 17.2 in ODL, Java process experiences very high
>> CPU utilization and I see the following logs in karaf.
>>
>> What is the meaning of "Unexpected response to get-schema, expected
>> response with one child (urn:ietf:params:xml:ns:yang:i
>> etf-netconf-monitoring?revision=2010-10-04)data, but was
>> ImmutableContainerNode{nodeIdentifier=(urn:ietf:params:xml:
>> ns:yang:ietf-netconf-monitoring?revision=2010-10-04)output, value=[],
>> attributes={()message-id=m-61}}" ?
>>
>> 2017-07-09 18:46:29,850 | WARN  | oupCloseable-3-6 |
>> NetconfXMLToMessageDecoder   | 124 - org.opendaylight.netconf.netty-util
>> - 1.1.3.Boron-SR3 | XML message with unwanted leading bytes detected.
>> Discarded the 1 leading byte(s): '0a'
>>
>
> I'm no expert in this area, but this sounds like the XML sent by that
> device perhaps starts with an empty new line? NB 0a is LF... that's
> considered invalid - and some XML parser in ODL chokes on that.
>

Actually ODL detects the trailing characters and discards it, it doesn't
choke on that ;)


>
>
> Tx,
>
M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com
>  | IRC: vorburger
> @freenode | ~ = http://vorburger.ch
>
>
>> 2017-07-09 18:46:29,855 | DEBUG | oupCloseable-3-6 |
>> AbstractProtocolSession  | 84 - 
>> org.opendaylight.controller.protocol-framework
>> - 0.8.3.Boron-SR3 | Message was received: > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="
>> http://xml.juniper.net/junos/17.2R1/junos; message-id="m-61">
>> ...cut...
>>
>> 2017-07-09 18:46:29,855 | DEBUG | oupCloseable-3-6 |
>> AbstractNetconfSession   | 124 - org.opendaylight.netconf.netty-util
>> - 1.1.3.Boron-SR3 | handling incoming message
>>
>> 2017-07-09 18:46:29,858 | DEBUG | oupCloseable-3-6 |
>> NetconfDeviceCommunicator| 289 - 
>> org.opendaylight.netconf.sal-netconf-connector
>> - 1.4.3.Boron-SR3 | RemoteDevice{R1}: Message received > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="
>> http://xml.juniper.net/junos/17.2R1/junos; message-id="m-61">
>> ...cut...
>>
>> 2017-07-09 18:46:29,859 | DEBUG | oupCloseable-3-6 |
>> AbstractSchemaRepository | 87 - 
>> org.opendaylight.yangtools.yang-model-util
>> - 1.0.3.Boron-SR3 | Failed to acquire source from
>> AbstractObjectRegistration{instance=org.opendaylight.yangtoo
>> ls.yang.model.repo.spi.PotentialSchemaSource@10147885}
>> java.lang.IllegalStateException: RemoteDevice{R1} Unexpected response to
>> get-schema, expected response with one child (urn:ietf:params:xml:ns:yang:i
>> etf-netconf-monitoring?revision=2010-10-04)data, but was
>> ImmutableContainerNode{nodeIdentifier=(urn:ietf:params:xml:
>> ns:yang:ietf-netconf-monitoring?revision=2010-10-04)output, value=[],
>> attributes={()message-id=m-61}}
>>
>> 2017-07-09 18:46:29,859 | DEBUG | oupCloseable-3-6 |
>> AbstractSchemaRepository | 87 - 
>> org.opendaylight.yangtools.yang-model-util
>> - 1.0.3.Boron-SR3 | Failed to acquire source from
>> AbstractObjectRegistration{instance=org.opendaylight.yangtoo
>> ls.yang.model.repo.spi.PotentialSchemaSource@5e08e193}
>> org.opendaylight.yangtools.yang.model.repo.api.MissingSchemaSourceException:
>> All available providers exhausted
>>
>>
>> Abdelmuhaimen Seaudi, CCIE # 25265
>> Email: asea...@gmail.com
>> 
>> Skype: aseaudi
>> LinkedIn: www.linkedin.com/in/aseaudi
>> Telephone: +2012 84644 733
>>
>>
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> 
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] [netconf-dev] issues when mounting junos 17.2 in ODL

2017-07-10 Thread Alexis de Talhouët 
Le lundi 10 juillet 2017, Abdelmuhaimen Seaudi > a écrit :

> Hi,
>
> When I try to mount Junos 17.2 in ODL, Java process experiences very high
> CPU utilization and I see the following logs in karaf.
>

If I'm not mistaking, That version of Junos contains a lot of schemas to be
downloaded be ODL during session establishment, I faced the a similar issue
reported here https://bugs.opendaylight.org/show_bug.cgi?id=8569
It boils down to the fact Yangtools is using a lot à resources to
dynamically generate SchemaContext for the NETCONF device.


>
> What is the meaning of "Unexpected response to get-schema, expected
> response with one child (urn:ietf:params:xml:ns:yang:i
> etf-netconf-monitoring?revision=2010-10-04)data, but was
> ImmutableContainerNode{nodeIdentifier=(urn:ietf:params:xml:
> ns:yang:ietf-netconf-monitoring?revision=2010-10-04)output, value=[],
> attributes={()message-id=m-61}}" ?
>
>
Looks like ietf-netconf-monitoring get-schema rpc contatct was not respect
by the device.
The Roc defining is expecting one child node being "data" in the reply, but
the device returns something different, in this case "output".
This would be a Junos problem.

HTH,
Alexis


>
>
>
>
> 2017-07-09 18:46:29,850 | WARN  | oupCloseable-3-6 |
> NetconfXMLToMessageDecoder   | 124 - org.opendaylight.netconf.netty-util
> - 1.1.3.Boron-SR3 | XML message with unwanted leading bytes detected.
> Discarded the 1 leading byte(s): '0a'
>
> 2017-07-09 18:46:29,855 | DEBUG | oupCloseable-3-6 |
> AbstractProtocolSession  | 84 - 
> org.opendaylight.controller.protocol-framework
> - 0.8.3.Boron-SR3 | Message was received:  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="
> http://xml.juniper.net/junos/17.2R1/junos; message-id="m-61">
> ...cut...
>
> 2017-07-09 18:46:29,855 | DEBUG | oupCloseable-3-6 |
> AbstractNetconfSession   | 124 - org.opendaylight.netconf.netty-util
> - 1.1.3.Boron-SR3 | handling incoming message
>
> 2017-07-09 18:46:29,858 | DEBUG | oupCloseable-3-6 |
> NetconfDeviceCommunicator| 289 - 
> org.opendaylight.netconf.sal-netconf-connector
> - 1.4.3.Boron-SR3 | RemoteDevice{R1}: Message received  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="
> http://xml.juniper.net/junos/17.2R1/junos; message-id="m-61">
> ...cut...
>
> 2017-07-09 18:46:29,859 | DEBUG | oupCloseable-3-6 |
> AbstractSchemaRepository | 87 - 
> org.opendaylight.yangtools.yang-model-util
> - 1.0.3.Boron-SR3 | Failed to acquire source from
> AbstractObjectRegistration{instance=org.opendaylight.yangtoo
> ls.yang.model.repo.spi.PotentialSchemaSource@10147885}
> java.lang.IllegalStateException: RemoteDevice{R1} Unexpected response to
> get-schema, expected response with one child (urn:ietf:params:xml:ns:yang:i
> etf-netconf-monitoring?revision=2010-10-04)data, but was
> ImmutableContainerNode{nodeIdentifier=(urn:ietf:params:xml:
> ns:yang:ietf-netconf-monitoring?revision=2010-10-04)output, value=[],
> attributes={()message-id=m-61}}
>
> 2017-07-09 18:46:29,859 | DEBUG | oupCloseable-3-6 |
> AbstractSchemaRepository | 87 - 
> org.opendaylight.yangtools.yang-model-util
> - 1.0.3.Boron-SR3 | Failed to acquire source from
> AbstractObjectRegistration{instance=org.opendaylight.yangtoo
> ls.yang.model.repo.spi.PotentialSchemaSource@5e08e193}
> org.opendaylight.yangtools.yang.model.repo.api.MissingSchemaSourceException:
> All available providers exhausted
>
>
> Abdelmuhaimen Seaudi, CCIE # 25265
> Email: asea...@gmail.com
> Skype: aseaudi
> LinkedIn: www.linkedin.com/in/aseaudi
> Telephone: +2012 84644 733
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] How to create CDS shards

2017-02-02 Thread Alexis de Talhouët 

> On Feb 2, 2017, at 5:26 PM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> 
>> On Feb 2, 2017, at 5:24 PM, Tom Pantelis <tompante...@gmail.com 
>> <mailto:tompante...@gmail.com>> wrote:
>> 
>> Alexis,
>> 
>> On a side note, I was curious about the purpose of the mount point cache. 
>> Can you explain a bit more?
> 
> Here is the explanation:

Basically, the purpose is to be able to dynamically load yang model, and to be 
able to interact with them to finally do whatever you want in the SB layer. And 
there is no possibility as of today to do so in ODL. So this cache mount point 
allows one to side-load model, and to have them backed by an actual instance of 
the datastore, without having any device behind (similar as NETCONF, but the 
device is the datastore).

> 
> Bug Tracking: https://bugs.opendaylight.org/show_bug.cgi?id=7522 
> <https://bugs.opendaylight.org/show_bug.cgi?id=7522>
> Note: 
> https://meetings.opendaylight.org/opendaylight-meeting/2017/tws/opendaylight-meeting-tws.2017-01-30-18.01.log.html
>  
> <https://meetings.opendaylight.org/opendaylight-meeting/2017/tws/opendaylight-meeting-tws.2017-01-30-18.01.log.html>
> Recording: 
> https://meetings.webex.com/collabs/#/meetings/detail?uuid=I9FFEQ5TEML679ALSDH6M545W1-9VIB
>  
> <https://meetings.webex.com/collabs/#/meetings/detail?uuid=I9FFEQ5TEML679ALSDH6M545W1-9VIB>
>> 
>> The Conceptual Data Tree stuff does have an API to dynamically create 
>> prefixed shards. However the patches to implement the new APIs in CDS is 
>> still in progress. Tomas Cere is working on that.
> 
> Ah, make sense I wasn't able to do so then.
> 
> Thanks for the answer.
> 
>> 
>> Tom
>> 
>> On Thu, Feb 2, 2017 at 5:04 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.com>> wrote:
>> Hello controller-dev,
>> 
>> While creating this little PoC [0] to dynamically mount yang models, I tried 
>> to create a CDS shard to backed the created SchemaContext in the datastore, 
>> but wasn't able to achieve this, so I create an InMemoryDataStore instance, 
>> which is super easy to do, see [1].
>> 
>> Is there any written guide to create CDS shard and to interact with it? 
>> (Unfortunatly I guess this is a rethorical question, but had to mentioned it 
>> anyway) 
>> All I could find was [2], but I believe it's still WIP, and I wasn't able to 
>> understand how transaction are created for that particular shard.
>> 
>> Also considering the amoung of code in the sal-distributed-datastore, I'd 
>> appreciate if someone could help me towards achieving my goal, and I'll 
>> setup a wiki to explain to process :)
>> 
>> Thanks,
>> Alexis
>> 
>> [0]: https://github.com/adetalhouet/cached-mountpoint 
>> <https://github.com/adetalhouet/cached-mountpoint>
>> [1]: 
>> https://github.com/adetalhouet/cached-mountpoint/blob/master/impl/src/main/java/org/opendaylight/mdsal/mount/cache/impl/InMemoryDeviceDOMDataStorePool.java#L63
>>  
>> <https://github.com/adetalhouet/cached-mountpoint/blob/master/impl/src/main/java/org/opendaylight/mdsal/mount/cache/impl/InMemoryDeviceDOMDataStorePool.java#L63>
>> [2]: https://git.opendaylight.org/gerrit/#/c/49174/ 
>> <https://git.opendaylight.org/gerrit/#/c/49174/>
>> 
>> 
> 

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] How to create CDS shards

2017-02-02 Thread Alexis de Talhouët 

> On Feb 2, 2017, at 5:24 PM, Tom Pantelis <tompante...@gmail.com> wrote:
> 
> Alexis,
> 
> On a side note, I was curious about the purpose of the mount point cache. Can 
> you explain a bit more?

Here is the explanation:

Bug Tracking: https://bugs.opendaylight.org/show_bug.cgi?id=7522 
<https://bugs.opendaylight.org/show_bug.cgi?id=7522>
Note: 
https://meetings.opendaylight.org/opendaylight-meeting/2017/tws/opendaylight-meeting-tws.2017-01-30-18.01.log.html
 
<https://meetings.opendaylight.org/opendaylight-meeting/2017/tws/opendaylight-meeting-tws.2017-01-30-18.01.log.html>
Recording: 
https://meetings.webex.com/collabs/#/meetings/detail?uuid=I9FFEQ5TEML679ALSDH6M545W1-9VIB
 
<https://meetings.webex.com/collabs/#/meetings/detail?uuid=I9FFEQ5TEML679ALSDH6M545W1-9VIB>
> 
> The Conceptual Data Tree stuff does have an API to dynamically create 
> prefixed shards. However the patches to implement the new APIs in CDS is 
> still in progress. Tomas Cere is working on that.

Ah, make sense I wasn't able to do so then.

Thanks for the answer.

> 
> Tom
> 
> On Thu, Feb 2, 2017 at 5:04 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
> Hello controller-dev,
> 
> While creating this little PoC [0] to dynamically mount yang models, I tried 
> to create a CDS shard to backed the created SchemaContext in the datastore, 
> but wasn't able to achieve this, so I create an InMemoryDataStore instance, 
> which is super easy to do, see [1].
> 
> Is there any written guide to create CDS shard and to interact with it? 
> (Unfortunatly I guess this is a rethorical question, but had to mentioned it 
> anyway) 
> All I could find was [2], but I believe it's still WIP, and I wasn't able to 
> understand how transaction are created for that particular shard.
> 
> Also considering the amoung of code in the sal-distributed-datastore, I'd 
> appreciate if someone could help me towards achieving my goal, and I'll setup 
> a wiki to explain to process :)
> 
> Thanks,
> Alexis
> 
> [0]: https://github.com/adetalhouet/cached-mountpoint 
> <https://github.com/adetalhouet/cached-mountpoint>
> [1]: 
> https://github.com/adetalhouet/cached-mountpoint/blob/master/impl/src/main/java/org/opendaylight/mdsal/mount/cache/impl/InMemoryDeviceDOMDataStorePool.java#L63
>  
> <https://github.com/adetalhouet/cached-mountpoint/blob/master/impl/src/main/java/org/opendaylight/mdsal/mount/cache/impl/InMemoryDeviceDOMDataStorePool.java#L63>
> [2]: https://git.opendaylight.org/gerrit/#/c/49174/ 
> <https://git.opendaylight.org/gerrit/#/c/49174/>
> 
> 

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Interfacemanager blueprint migration, dependency issues, need help

2017-01-20 Thread Alexis de Talhouët 
Michael,

I recall at the time I initially moved netvirt to blueprint, I faced cyclic 
dependency. The approach I used is the following:
Instead of having the blueprint resolved the service you need, which end up 
having deadlock due to cyclic dependency, resolve the service you need using 
WaitingServiceTracker in the class needing the service. So the blueprint 
containers will be able to start, and once started, the service should become 
available in the OSGi Registry, making them available to be retrieved by a 
ServiceTracker.

At the time, it was FibManager and VpnManager that had a cyclic dependency, 
hence I've done this in FibManager:
https://git.opendaylight.org/gerrit/#/c/38991/29/vpnservice/fibmanager/fibmanager-impl/src/main/java/org/opendaylight/netvirt/fibmanager/FibManagerImpl.java@34
 

 and this in VpnManager: 
https://git.opendaylight.org/gerrit/#/c/39012/19/vpnservice/vpnmanager/vpnmanager-impl/src/main/java/org/opendaylight/netvirt/vpnmanager/VpnInterfaceManager.java@152
 


Hoe this helps,
Alexis

 
> On Jan 20, 2017, at 8:42 AM, Michael Vorburger  wrote:
> 
> On Fri, Jan 20, 2017 at 12:23 AM, Robert Varga  > wrote:
> On 01/19/2017 07:21 PM, Robert Varga wrote:
> > He has cooked up https://git.opendaylight.org/gerrit/50682 
> >  to correct
> > that, which I think will make the issue more obvious and probably split
> > this conversation into multiple tracks.
> 
> With the patch the error is actually more useful for BUG-3128 case (and
> confirms what I suspected is the underlying root cause):
> 
> 21:53:42 2. NOK
> org.opendaylight.openflowplugin.applications.lldp-speaker: OSGi state =
> Active, Karaf bundleState = GracePeriod, due to: Blueprint
> 21:53:42 1/19/17 9:46 PM
> 21:53:42 Missing dependencies:
> 21:53:42 Available DOM RPC for binding RPC: interface
> org.opendaylight.yang.gen.v1.urn.opendaylight.packet.service.rev130709.PacketProcessingService
> 
> What does it say for the genius issue?
> 
> completely different issue there - we now see that there is a cyclic 
> dependency, which it looks like CSS was somehow able to handle, but blueprint 
> is not anymore. I'll follow-up with more details to genius-dev only, to spare 
> controller-dev the traffic about this now again purely genius internal 
> problem (if anyone is interest in a detailed discussion how to analyse and 
> resolve a cyclic dependency with blueprint, please follow the continuing 
> thread with the same subject on genius-dev).
> 
> Tom, THANK YOU so much for https://git.opendaylight.org/gerrit/#/c/50682/ 
>  !!! Makes a world of 
> difference to analyse these kind of problems.
>  
> 
> Bye,
> Robert
> 
> 
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org 
> 
> https://lists.opendaylight.org/mailman/listinfo/controller-dev 
> 
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] No local or remote implementation available for routed-rpc

2016-12-06 Thread Alexis de Talhouët 
Hello,

Please follow this guide [0], it should guide you through the complete 
implementation of an RPC. 

Once you've modeled the RPC, you have to implement it, using the generated 
interface, in your case, it would be HelloService.java. And then you have to 
register the implementation in this RpcProviderRegistry.

The error message you're seeing means you're calling an RPC that doesn't have 
any registered implementation.

Hope this helps,
Alexis

[0]: 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype#Adding_a_very_simple_HelloWorld_RPC_api
 


> On Dec 6, 2016, at 2:56 AM, 风驰天下 <609790...@qq.com> wrote:
> 
> Hi,everyone.
> 
> I added a routed-rpc to my hello-app,here is the yang profile:
> 
> module hello {
>  yang-version 1;
>  namespace "urn:opendaylight:params:xml:ns:yang:hello";
>  prefix "hello";
> 
>  import yang-ext { prefix ext; }
> 
> revision "2015-01-05" {
> description "Initial revision of hello model";
> }
> container helloSimpleNode{
> leaf simpleData{
> type string;
>  }
> }
> 
> identity hello-world-context {
> description "Test Routed RPC Context";
> }
> 
> list rpc-member {
> config false;
> leaf name {
> type string;
> description
> "";
> }
> key "name";
> }
> 
> rpc hello-world {
> input {
> leaf route {
> type instance-identifier;
> ext:context-reference hello-world-context;
> description
> 'Identifies the RPC instance to which the RPC call
> should be routed. The instance identifier for the routed
> RPC in this example must in the following format:
> /routed-rpc:rpc-member[routed-rpc:name="rpc-key"]';
> }
> leaf name{
> type string;
> }
> }
> output{
> leaf greeting{
> type string;
> }
> leaf invocations{
> type int32;
> }
> leaf host-name{
> type string;
> }
> leaf jvm-uptime{
> type int64;
> }
> leaf-list ip-address{
> type string;
> }
> }
> }
> notification helloNotification{
> leaf note{
> type string;
> }
>   }
> }
> 
> Then I added input params into this rpc but with this error:
> <33992...@42253629.2b6f4658.png>
> 
> error-message:"No local or remote implementation available for rpc 
> AbsoluteSchemaPath{path=[(urn:opendaylight:params:xml:ns:yang:hello?revision=2015-01-05)hello-world]}"
> 
>Is this a input format error?
> 
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] Memory leaks on blueprint restart

2016-11-10 Thread Alexis de Talhouët 

> On Nov 10, 2016, at 11:35 AM, Colin Dixon  wrote:
> 
> I realize I'm getting here late, but did we get an issue opened.

If I’m not mistaking, yes, and it is that one: 
https://bugs.opendaylight.org/show_bug.cgi?id=6969 


> Have we made any progress?

I personally haven’t looked into it yet. I don’t know about TomP.

Thanks,
Alexis___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [yangtools-dev] Yang 1.1 call

2016-10-17 Thread Alexis de Talhouët 
Rashmi is on PTO for two weeks, but she would agree, so by delegation, here is 
her +1.

Thanks,
Alexis
> On Oct 17, 2016, at 10:44 AM, Ryan Goulding  wrote:
> 
> +1 this works great for me.  Others please chime in so we can resolve this 
> for next week and have our first meeting.
> 
> Regards,
> 
> Ryan Goulding
> 
> On Mon, Oct 17, 2016 at 9:58 AM, Martin Ciglan -X (mciglan - PANTHEON 
> TECHNOLOGIES at Cisco) > wrote:
> ​Hi all
> 
> 
> 
> As a first proposal, I suggest 3PM CET (1PM UTC daylight saving, it should be 
> 7AM Denver, 9AM Montreal), 1 hour duration on Monday, weekly basis.
> 
> It doesn't seem to collide with anything in 
> https://wiki.opendaylight.org/view/Meetings 
> 
> I assume we should use Webex with recording feature as we always do.
> 
> Please let me know your opinions.
> 
> 
> 
>Best Regards
> 
> 
> 
> Martin
> 
>   
> 
> Od: yangtools-dev-boun...@lists.opendaylight.org 
>  
>  > v mene používateľa 
> Peter Verthez >
> Odoslané: 14. októbra 2016 13:33
> Komu: Ryan Goulding; Rashmi Pujar
> Kópia: controller-dev; Viera Zelcamova -X (vzelcamo - PANTHEON TECHNOLOGIES 
> at Cisco); yangtools-dev
> Predmet: Re: [yangtools-dev] [controller-dev] Yang 1.1 call
>  
> Hi all,
> 
> Thanks for starting this discussion, because we are looking forward to the 
> support of YANG 1.1 in OpenDaylight.
> 
> Unfortunately we don't have resources in our company that can help in the 
> development of this, but if it may help in priority setting for the different 
> subtasks: the YANG 1.1 features that we're encountering in the IETF models, 
> and which we have to comment out for the moment, are:
> - actions
> - use of derived-from-or-self function in when conditions
> 
> The models in question are from 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ 
> 
> 
> Other people may have different priorities of course.  This is just as our 
> input.
> 
> We will be happy to test intermediate builds if possible.
> 
> Best regards,
> Peter.
> 
> 
> On 14/10/2016 13:04, Ryan Goulding wrote: 
>> 
>> Thanks, Rashmi.  We will include you going forward.
>> 
>> Martin, have you had any luck setting up a meeting time slot for this 
>> endeavor?  If not, I can take a stab at it based on available upstream 
>> meeting times derived from the meetings wiki page [0].
>> 
>> Thanks,
>> 
>> Ryan
>> 
>> [0] https://wiki.opendaylight.org/view/Meetings 
>> 
>> On Tue, Oct 11, 2016 at 10:20 AM, Rashmi Pujar > > wrote:
>> Hi Ryan, Martin,
>> 
>> I am interested to participate in Yang1.1 effort. Please forward the meeting 
>> details once you have them.
>> Is there a Trello board that I need to subscribe to or the activity is 
>> tracked on bugzilla?
>> 
>> Thanks,
>> 
>> On Tue, Oct 11, 2016 at 9:39 AM, Ryan Goulding > > wrote:
>> Hi Martin,
>> 
>> I have included +yangtools-dev and +controller-dev in the cc list in attempt 
>> to recruit more people for this effort :).  My main point behind this is 
>> that these meetings should be open to the public community so we can drive 
>> inclusion and hopefully spread the workload for this big effort.
>> 
>> I am available to do work on Yang 1.1, as I stated in our last kernel 
>> projects call.  Similar to others, I split my time on many endeavors, but 
>> this is my main area of focus for this release.
>> 
>> Please let me know where/when this call will happen.  If we need help 
>> finding a time slot for webex, I can communicate with LF staff to set up the 
>> appropriate tools. 
>> 
>> Thanks,
>> 
>> Ryan
>> 
>> On Tue, Oct 11, 2016 at 8:40 AM, Martin Ciglan -X (mciglan - PANTHEON 
>> TECHNOLOGIES at Cisco) > wrote:
>> Hi Colin & Ryan
>> 
>> 
>> 
>> 'Yang 1.1 meetings' is still TO DO, we should be able to come up with more 
>> information next week.
>> 
>> For time being, can you specify how many people can participate, % 
>> commitment to be able to finish assigned bug(s), etc... ? 
>> 
>> 
>> 
>> Thank you in advance.
>> 
>> 
>> 
>> Best Regards
>> 
>> 
>> 
>>   Martin
>> 
>> 
>> 
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org 
>> 
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>>

Re: [controller-dev] [release] Memory leaks on blueprint restart

2016-10-13 Thread Alexis de Talhouët 
Are you saying we’re missing something? e.g. quiesce the list of Bundle that we 
be restarted, using [0]?

[0]: 
https://aries.apache.org/downloads/javadocs/quiesce/0.3/org/apache/aries/quiesce/manager/QuiesceManager.html#quiesce(java.util.List)
 
<https://aries.apache.org/downloads/javadocs/quiesce/0.3/org/apache/aries/quiesce/manager/QuiesceManager.html#quiesce(java.util.List)>


> On Oct 13, 2016, at 1:13 PM, Tom Pantelis <tompante...@gmail.com> wrote:
> 
> Aries registers each BlueprintContainer as an OSGI service but it doesn't 
> look like it unregisters it on destroy. It does appear to when the bundle is 
> stopping (via qiesce()). 
> 
> On Thu, Oct 13, 2016 at 1:00 PM, Martin Dindoffer 
> <martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech>> 
> wrote:
> The detailed path to GC roots starts like this:
> 
> org.opendaylight.topoprocessing.impl.provider.TopoProcessingProviderImpl @ 
> 0x88b54aa0
> '- service org.apache.aries.blueprint.container.ServiceRecipe @ 0x88b54720
>'- val java.util.concurrent.ConcurrentHashMap$Node @ 0x88b54700
>   '- next java.util.concurrent.ConcurrentHashMap$Node @ 0x88b54328
>  '- next java.util.concurrent.ConcurrentHashMap$Node @ 0x88b542f0
> '- [20] java.util.concurrent.ConcurrentHashMap$Node[32] @ 
> 0x88b53ae8
>'- table java.util.concurrent.ConcurrentHashMap @ 0x88b53aa8
>   '- recipes 
> org.apache.aries.blueprint.container.BlueprintRepository @ 0x88b53a80
>  '- repository 
> org.apache.aries.blueprint.container.BlueprintContainerImpl @ 0x88b38f98
> '- service 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl @ 0x88f51a20
> 
> The entire tree to the GC roots is huge. I'm putting it in pastebin: 
> http://pastebin.com/raw/HYtxGUbe <http://pastebin.com/raw/HYtxGUbe> (probably 
> need to download it to avoid line wrapping)
> 
> 
> Martin
> 
> 
> Od: Tom Pantelis <tompante...@gmail.com <mailto:tompante...@gmail.com>>
> Odoslané: 13. októbra 2016 18:33
> Komu: Alexis de Talhouët
> Kópia: Martin Dindoffer; rele...@lists.opendaylight.org 
> <mailto:rele...@lists.opendaylight.org>; controller-dev
> 
> Predmet: Re: [release] Memory leaks on blueprint restart
>  
> What object is hanging onto the 
> org.apache.aries.blueprint.container.ServiceRecipe? You need to follow the 
> references up the chain.
> 
> On Thu, Oct 13, 2016 at 12:26 PM, Alexis de Talhouët <adetalho...@inocybe.com 
> <mailto:adetalho...@inocybe.com>> wrote:
> I see, it looks good to me. Adding controller-dev that I missed and TomP, 
> initial contributor for the blueprint backend.
> 
> This issue should be somewhere in this class [0]. I don’t have time now to 
> investigate just now. If TomP says so, you can open a BUG against 
> controller/blueprint component.
> 
> Thanks,
> Alexis
> 
> [0]: 
> https://github.com/opendaylight/controller/blob/master/opendaylight/blueprint/src/main/java/org/opendaylight/controller/blueprint/BlueprintContainerRestartServiceImpl.java
>  
> <https://github.com/opendaylight/controller/blob/master/opendaylight/blueprint/src/main/java/org/opendaylight/controller/blueprint/BlueprintContainerRestartServiceImpl.java>
> 
> 
>> On Oct 13, 2016, at 12:18 PM, Martin Dindoffer 
>> <martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech>> 
>> wrote:
>> 
>> The blueprint xml is at 
>> topoprocessing-impl/src/main/resources/org/opendaylight/blueprint/topoprocessing.xml
>>  ( 
>> https://github.com/opendaylight/topoprocessing/blob/master/topoprocessing-impl/src/main/resources/org/opendaylight/blueprint/topoprocessing.xml
>>  
>> <https://github.com/opendaylight/topoprocessing/blob/master/topoprocessing-impl/src/main/resources/org/opendaylight/blueprint/topoprocessing.xml>
>>  ) 
>> Blueprint patches: 
>> https://git.opendaylight.org/gerrit/#/q/status:merged+project:topoprocessing+branch:master+topic:blueprint
>>  
>> <https://git.opendaylight.org/gerrit/#/q/status:merged+project:topoprocessing+branch:master+topic:blueprint>
>> The code you linked is from the CSS timeline, not used anymore. The 
>> TopoProcessingProviderModule class is now gone completely. We are relying 
>> solely on blueprint instantiation.
>> Od: Alexis de Talhouët <adetalho...@inocybe.com 
>> <mailto:adetalho...@inocybe.com>>
>> Odoslané: 13. októbra 2016 18:00
>> Komu: Martin Dindoffer
>> Kópia: rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>
>> Predmet: Re: [release] Memory leaks on blueprint resta

[controller-dev] Blueprint slide deck

2016-10-04 Thread Alexis de Talhouët 
Hello Tom,

Can you share your slide deck that you presented during the summit about 
blueprint?

Thanks,
Alexis
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] [openflowplugin-dev] Regression in OF cluster test

2016-09-07 Thread Alexis de Talhouët 
If I may intervene, Daniel would like to have those in RC3, but don’t want to 
respin the release, nor block it.
As it appears we will respin the release anyway, based on the initial mail of 
this thread. I understand that DLUX patches could get in.
All patches were reviewed and +2 by DLUX committer, and all BUGs listed by 
Daniel are raised as BLOCKER.

If there is indeed a respin happening, I guess those patches can get in.

To give a little bit of input regarding those patches, they are addressing the 
reviews made for the huge patch stack that was merged Aug 25:
https://git.opendaylight.org/gerrit/#/q/project:dlux+branch:stable/boron+topic:yangman-stable/boron+status:merged
 


Thanks,
Alexis

> On Sep 7, 2016, at 5:32 PM, An Ho  wrote:
> 
> I believe Daniel Malachovsky has stated to retarget this for Boron SR1 on 
> October 6, 2016 [1], which is roughly a month from now.
> 
> Best Regards,
> An Ho
> 
> [1] 
> https://lists.opendaylight.org/pipermail/release/2016-September/008168.html 
> 
> 
> -Original Message-
> From: Robert Varga [mailto:n...@hq.sk ] 
> Sent: Wednesday, September 07, 2016 2:26 PM
> To: An Ho; Colin Dixon; Philip Robb; Tom Pantelis; Anil Vishnoi
> Cc: controller-dev; openflowplugin-dev; rele...@lists.opendaylight.org 
> 
> Subject: Re: [controller-dev] [openflowplugin-dev] Regression in OF cluster 
> test
> 
> Hello An,
> 
> does this mean that the DLUX patches are free to go in?
> 
> Thanks,
> Robert
> 
> On 2016-09-07 22:02, An Ho wrote:
>> The CONTROLLER/OPENFLOWPLUGIN team and other folks met to discuss the 
>> status of this bug and the current plan of action is as follows:
>> 
>> 
>> 
>> 1. TomP & CONTROLLER team will remove the invalid test(s) as per Bug
>> 6659 [1].
>> 
>>   Deliverable: Patch(es) removing or fixing the tests.
>> 
>> 2. The release team will schedule a respin of RC3.2 with the VBD fix 
>> at
>> 9/7 23:59 UTC.
>> 
>>   Deliverable: Boron RC3.2 Common Karaf Disitrbution.
>> 
>> 3. Luis & OPENFLOWPLUGIN team will run OFP tests a few more times.
>> 
>>   Deliverable: Comment on bugzilla [2] to confirm if we only get the 
>> expected 26 failures in subsequent runs.
>> 
>> 4. Anil & OPENFLOWPLUGIN team will attempt to reproduce locally in 
>> order to establish if this is a real blocker.  We strongly recommend 
>> that the team enable "debug" on some runs while trying to reproduce the bug.
>> 
>>   Deliverable: Comment on bugzilla [2] to confirm if Bug 6658 is a 
>> real blocker.
>> 
>> 5. Luis & OPENFLOWPLUGIN team will fix the tests that are failing 
>> because of the change in behavior of candidate lists.
>> 
>>   Deliverable: Patch(es) fixing tests.
>> 
>> 
>> 
>> Best Regards,
>> 
>> An Ho
>> 
>> 
>> 
>> [1] https://bugs.opendaylight.org/show_bug.cgi?id=6659
>> 
>> [2] https://bugs.opendaylight.org/show_bug.cgi?id=6658
>> 
>> 
>> 
>> 
>> 
>> *From:*Colin Dixon [mailto:co...@colindixon.com]
>> *Sent:* Wednesday, September 07, 2016 10:35 AM
>> *To:* Abhijit Kumbhare
>> *Cc:* An Ho; controller-dev; rele...@lists.opendaylight.org; 
>> openflowplugin-dev
>> *Subject:* Re: [openflowplugin-dev] [controller-dev] Regression in OF 
>> cluster test
>> 
>> 
>> 
>> We're trying to figure that out, but if we could have somebody with 
>> experience in OpenFlow plugin clustering give their 2 cents on if it's 
>> a bug in the test or the behavior, that would really help.
>> 
>> Thanks,
>> 
>> --Colin
>> 
>> 
>> 
>> On Wed, Sep 7, 2016 at 1:33 PM, Abhijit Kumbhare 
>> > wrote:
>> 
>> Thanks Luis and An. If it is a test needing update rather than the 
>> code
>> - it might be better to keep Tom's fix.
>> 
>> 
>> 
>> On Wed, Sep 7, 2016 at 10:23 AM, An Ho > > wrote:
>> 
>>Still waiting to hear back from the controller team, but in the
>>meantime I have created the following blocker bug [1] and updated
>>the tracking spreadsheet.
>> 
>> 
>> 
>>Hopefully after updating the tests there will not be any issues found.
>> 
>> 
>> 
>>Best Regards,
>> 
>>An Ho
>> 
>> 
>> 
>>[1] https://bugs.opendaylight.org/show_bug.cgi?id=6658
>> 
>> 
>> 
>>*From:*Luis Gomez [mailto:ece...@gmail.com ]
>>*Sent:* Wednesday, September 07, 2016 10:07 AM
>>*To:* An Ho
>>*Cc:* controller-dev; openflowplugin-dev;
>>rele...@lists.opendaylight.org
>>; Tom Pantelis; Colin Dixon
>> 
>> 
>>*Subject:* Re: Regression in OF cluster test
>> 
>> 
>> 
>>So far I can see it mostly impacts entity-owner API behavior, so
>>updating the test cases will fix most of the failures. I am counting
>>1 day to update the test cases and

Re: [controller-dev] Unable to run karaf [Windows7]

2016-08-03 Thread Alexis de Talhouët 

> On Aug 3, 2016, at 4:45 PM, Robert Varga  wrote:
> 
> I do not know why have not seen this earlier, but I am pretty sure it is
> caused by https://git.opendaylight.org/gerrit/39982 
>  which addresses
> BUG-6027.

I’m sure you’ve seen it since you merged it, but those scripts had changed again
in this patch: https://git.opendaylight.org/gerrit/#/c/43030/ 


Regardless the patch, readlink is indeed used.

Thanks,
Alexis___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev