[controller-dev] Understanding Conceptual Data Tree

[Shirley Anend]

I was going through the slides and presentation in ODL summit on the
Conceptual Data Tree. A semblance I can think of is how DNS server
partitioning and forwarding can be realized. If I have to draw parallels
wrt Conceptual Data Tree, there is a possibility of root, children and
grandchildren shards as a composite structure. Writes and reads are
recursively delegated to shards / sub-shards as per shard-layout. Is my
understanding better at this high-level ?

Now. specific assumptions (before going into transactions, ACID,
concistency etc.). So, please correct if following assumptions are right

1. With Conceptual Data Tree, a shard-implemention "claims" read/write
responsibility for a given subtree and become composite part of
shard-layout. This offers a more fine-grained sharding layout when compared
to current module-sharding layout of CDS

2. Above point also - hypothetically, implies that we can have a
shard-implementation (with suitable SPI abstractions of MD-SAL) which can
use an external datastore oher than CDS (eg. a clustered IMDG like Apache
Ignite or other suitable nosql solutions can be used as backend - in theory)

3. An external backend for shard may not provide all contractual
cpabilities as ODL CDS or IMDS. For example, change notifications. I
surmise it would be a great impedance mismatch to seal if capabilities like
listeners are provided agnostic to backend capabilities. Please correct me
if I am wrong

4. Shard-partitioning - as proposed by Conceptual Data Tree, is
schema-based or instance-based ? for example, can a list can be
range-partitioned by key and expressed that way in shard-layout
configuration without any changes in model ?
I understand that there is a possibility that list - as container, can be
owned by a shard and its backend may choose to partition it agnostic to the
shard-layout of CDT - this is what I refer as schema-based partitioning.
There is another possibility of expressing sharding meta in model - but
that pollutes domain model - so not a nice option. A rough example of
instance-based partitioning - create a dedicated shard for each
openflow-switch (unless such a design approach is audacious from resource
consumption perspective)

As mentioned, I have further questions as to what CDT means in terms of
transactions, ACID properties of transactions, Concistency model of
individual shards etc when a non-CDS backend is involved. But, I would be
able to better articulate my subsequent queries based on above
clarifications


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

[controller-dev] how to update bundles but doesn’t affect the service

[wang . jun24]

hello,everyone!
 Recently I don‘t known how to update bundles but  doesn’t affect the 
service (such as In-Service Software Upgrade )！

 for example: bundle A 1.00.10 want  update to bundle A 1.00.11，whether 
there is a mechanism to ensure the operation , does not affect the bundle 
A‘s normal service in ODL !

 Then I wander if there are any documents which can help me know about the 
problem，thanks！
 

 Best wishes!

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

[controller-dev] Lombok

[Sela, Guy]

Hi,

Did anyone consider adding Lombok into ODL?

https://projectlombok.org/features/
https://gualtierotesta.wordpress.com/2014/03/03/tutorial-using-lombok-to-reduce-boilerplate-code-in-java/


Thanks,
Guy Sela

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

[controller-dev] Regarding Colin's preso about message bus instead of MD-SAL proprietary events

[Sela, Guy]

Maybe this could be used to replace the Pure Notifications?
https://github.com/bennidi/mbassador



Thanks,
Guy Sela

___
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

[Tom Pantelis]

I think BlueprintContainer has a memory leak. Maybe we can work around it
by shutting it down via "quiescing" instead of destroy.

On Thu, Oct 13, 2016 at 1:28 PM, Alexis de Talhouët  wrote:

> 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)
>
>
> On Oct 13, 2016, at 1:13 PM, Tom Pantelis  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> 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.serv
>> iceregistry.ServiceRegistrationImpl @ 0x88f51a20
>>
>>
>> The entire tree to the GC roots is huge. I'm putting it in pastebin:
>> http://pastebin.com/raw/HYtxGUbe (probably need to download it to avoid
>> line wrapping)
>>
>>
>> Martin
>>
>>
>> *Od:* Tom Pantelis 
>> *Odoslané:* 13. októbra 2016 18:33
>> *Komu:* Alexis de Talhouët
>> *Kópia:* Martin Dindoffer; 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> 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/contro
>>> ller/blueprint/BlueprintContainerRestartServiceImpl.java
>>>
>>>
>>> On Oct 13, 2016, at 12:18 PM, Martin Dindoffer <
>>> martin.dindof...@pantheon.tech> wrote:
>>>
>>>
>>>- The blueprint xml is at topoprocessing-impl/src/main/r
>>>esources/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.opendayli
>>>ght.org/gerrit/#/q/status:merged+project:topoprocessing+bran
>>>ch: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 
>>> *Odoslané:* 13. októbra 2016 18:00
>>> *Komu:* Martin Dindoffer
>>> *Kópia:* rele...@lists.opendaylight.org
>>> *Predmet:* Re: [release] Memory leaks on blueprint restart
>>>
>>> + controller-dev
>>>
>>> Martin,
>>>
>>> Can you give the following pointers:
>>>
>>> - Where is the blueprint file?
>>> - Can you link the patch(es) that moved the project to blueprint so we
>>> can spot issues?
>>>
>>> Looking here [0] it seems that you create a new TopoProcessingProviderImpl
>>> each time the module is loaded, which is wrong if you’re using blueprint,
>>> see [1] for more references.
>>>
>>> Thanks,
>>> Alexis
>>>
>>> [0]: https://github.com/opendaylight/topoprocessing/blob/18e
>>> 7eb3e6615336e6c66fc26789456db76b97d95/topoprocessing-impl/sr
>>> c/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/p
>>> 

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

[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)
 



> On Oct 13, 2016, at 1:13 PM, Tom Pantelis  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 
> > 
> 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  (probably 
> need to download it to avoid line wrapping)
> 
> 
> Martin
> 
> 
> Od: Tom Pantelis >
> Odoslané: 13. októbra 2016 18:33
> Komu: Alexis de Talhouët
> Kópia: Martin Dindoffer; 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  > 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
>  
> 
> 
> 
>> On Oct 13, 2016, at 12:18 PM, Martin Dindoffer 
>> > 
>> 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
>>  
>> 
>>  ) 
>> Blueprint patches: 
>> 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 > >
>> Odoslané: 13. októbra 2016 18:00
>> Komu: Martin Dindoffer
>> Kópia: rele...@lists.opendaylight.org 
>> Predmet: Re: [release] Memory leaks on blueprint restart
>>  
>> + controller-dev
>> 
>> Martin,
>> 
>> Can you give the following pointers:
>> 
>> - Where is the blueprint file?
>> - Can you link the patch(es) that moved the project to blueprint so we can 
>> spot issues?
>> 
>> Looking here [0] it seems that you create a new TopoProcessingProviderImpl 
>> each time the module is loaded, which is wrong if you’re using blueprint, 
>> see [1] for more references.
>> 
>> Thanks,
>> Alexis
>> 
>> [0]: 
>> 

Re: [controller-dev] Netconf & Openflow Topology Differs?

[Giles Heron]

The netconf topology is just a list of nodes.  The OpenFlow topology also has 
links.

The topology is really the fundamental abstraction in ODL.   But some 
topologies (e.g. Netconf, PCE-P, IPv4/v6 unicast etc.) are just lists of nodes 
(often augmented with other information) whilst others (e.g. OpenFlow, 
Linkstate) also have links.

if you want to figure out the connectivity between a set of netconf nodes you 
can do that if the nodes support e.g. LLDP with a YANG model.   But then you’d 
be creating a new “topology” for LLDP.

> On 13 Oct 2016, at 07:58, Humera Kouser  
> wrote:
> 
> Hi,
> ​
> I want to know, how topology is different for netconf and openflow ?
> 
> How can I analyze the same in opendaylight?
> 
> 
> Suppose i have openflow and nonopenflow devices with netconf protocol for 
> configuration,
> how is that differed for openflow and netconf ?
> 
> Please anyone provide information on this or  document to refer.
> 
> 
> 
> Thanks & Regards,
> Humera
> L Technology Services Ltd
> www.LntTechservices.com 
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
> ___
> 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