I recommend you engage upstream Apache Karaf; they maintain and are
familiar with those modules. They are not written nor maintained by ODL
Developers.
HTH.
Regards,
Ryan Goulding
On Fri, Jun 8, 2018 at 6:37 AM, Steubert Ebenezer <
steuber...@altencalsoftlabs.com> wrote:
> Hi Ryan,
>
>
>
> T
Hi Robert,
On Fri, Jun 8, 2018 at 12:12 AM, Robert Varga wrote:
> On 07/06/18 19:14, Michael Vorburger wrote:
> > Robert,
> >
> > just to avoid any misunderstandings and unnecessary extra work to throw
> > away, may we double check and confirm that we correctly understand your
> > comment in ht
Tom,
On Thu, Jun 7, 2018 at 8:37 PM, Tom Pantelis wrote:
> On Thu, Jun 7, 2018 at 1:14 PM, Michael Vorburger
> wrote:
>
>> Robert,
>>
>> just to avoid any misunderstandings and unnecessary extra work to throw
>> away, may we double check and confirm that we correctly understand your
>> comment
On Fri, Jun 8, 2018 at 9:58 AM, Michael Vorburger
wrote:
> Tom,
>
> On Thu, Jun 7, 2018 at 8:37 PM, Tom Pantelis
> wrote:
>
>> On Thu, Jun 7, 2018 at 1:14 PM, Michael Vorburger
>> wrote:
>>
>>> Robert,
>>>
>>> just to avoid any misunderstandings and unnecessary extra work to throw
>>> away, may
Hi All,
I hope you are doing well. I am fairly new to the OpenDaylight framework
and trying to get a finer understanding of the MD-SAL infrastructure. To
get started, I am trying to develop the complete *Toaster* example from
scratch using *odl-startup-archetype*. I am following the tutorial:
http
Hi Ryan,
Thanks for your response.
We need to salt and hash the karaf CLI user passwords.
We installed jasypt (feature:install jasypt) on controller and modified
[karf.dir]/etc/org.apache.karaf.jaas.cfg as below.
encryption.name = jasypt
encryption.saltSizeBytes = 16
Now we crea
Pranjal,
The archetype generates initial suggested directories. There's really no
rules on how to organize the code - in the end it's your code and up to
you. The toaster example has the RPC implementation in a provider bundle
and an RPC user in a consumer bundle but it's just an example. If you h
On Thu, Jun 7, 2018 at 11:37 AM, Tom Pantelis wrote:
>
>
> On Thu, Jun 7, 2018 at 1:14 PM, Michael Vorburger
> wrote:
>
>> Robert,
>>
>> just to avoid any misunderstandings and unnecessary extra work to throw
>> away, may we double check and confirm that we correctly understand your
>> comment i
On Thu, Jun 7, 2018 at 11:39 AM, Faseela K wrote:
> Not related in this context, but if we can get shard leader change
> notification, can we use that to derive an entity owner instead of using
> EOS? ;)
>
Humble suggestion, don't use shard location/ownership status in your
business logic ;-)
On Fri, Jun 8, 2018 at 3:10 PM, Anil Vishnoi wrote:
>
>
> On Thu, Jun 7, 2018 at 11:37 AM, Tom Pantelis
> wrote:
>
>>
>>
>> On Thu, Jun 7, 2018 at 1:14 PM, Michael Vorburger
>> wrote:
>>
>>> Robert,
>>>
>>> just to avoid any misunderstandings and unnecessary extra work to throw
>>> away, may we
On Fri, Jun 8, 2018 at 3:11 PM, Anil Vishnoi wrote:
>
>
> On Thu, Jun 7, 2018 at 11:39 AM, Faseela K wrote:
>
>> Not related in this context, but if we can get shard leader change
>> notification, can we use that to derive an entity owner instead of using
>> EOS? ;)
>>
> Humble suggestion, don'
On Fri, Jun 8, 2018 at 1:49 PM, Tom Pantelis wrote:
>
>
> On Fri, Jun 8, 2018 at 3:10 PM, Anil Vishnoi
> wrote:
>
>>
>>
>> On Thu, Jun 7, 2018 at 11:37 AM, Tom Pantelis
>> wrote:
>>
>>>
>>>
>>> On Thu, Jun 7, 2018 at 1:14 PM, Michael Vorburger
>>> wrote:
>>>
Robert,
just to avoi
On 08/06/18 23:02, Anil Vishnoi wrote:
>
> All yang notifications are local - not sure what you mean by routed.
>
> I mean, like we route RPC's, i was wondering if you are building
> something that will route the yang notification as well to other node.
>
Not until someone implements
On Fri, Jun 8, 2018 at 5:02 PM, Anil Vishnoi wrote:
>
>
> On Fri, Jun 8, 2018 at 1:49 PM, Tom Pantelis
> wrote:
>
>>
>>
>> On Fri, Jun 8, 2018 at 3:10 PM, Anil Vishnoi
>> wrote:
>>
>>>
>>>
>>> On Thu, Jun 7, 2018 at 11:37 AM, Tom Pantelis
>>> wrote:
>>>
On Thu, Jun 7, 2018 at 1:
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Saturday, June 09, 2018 2:24 AM
To: Anil Vishnoi
Cc: Faseela K ; Michael Vorburger
; infrautils-...@lists.opendaylight.org; controller-dev
; genius-...@lists.opendaylight.org
Subject: Re: [controller-dev] [infrautils-dev] OK to resurrect
On Fri, Jun 8, 2018 at 4:50 PM, Faseela K wrote:
>
>
>
>
> *From:* Tom Pantelis [mailto:tompante...@gmail.com]
> *Sent:* Saturday, June 09, 2018 2:24 AM
> *To:* Anil Vishnoi
> *Cc:* Faseela K ; Michael Vorburger <
> vorbur...@redhat.com>; infrautils-...@lists.opendaylight.org;
> controller-dev ;
[Changed the subject]
Anil, now you can ask ;)
https://wiki.opendaylight.org/view/Genius:Sharding_evolution
Thanks,
Faseela
From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Saturday, June 09, 2018 5:30 AM
To: Faseela K
Cc: Tom Pantelis ; Michael Vorburger
; infrautils-...@lists.openday
So reading the wiki page, i was able to understand that there are two main
issues
(1) Transaction management and rollback -- i was not able to figure out the
relevance with distributed shard location.
(2) Performance in cluster node -- if shard leaders are distributed, any
transaction will involve
On 09/06/18 02:06, Faseela K wrote:
> [Changed the subject]
>
>
>
> Anil, now you can ask ;)
>
>
>
> https://wiki.opendaylight.org/view/Genius:Sharding_evolution
>
MD-SAL long-term design:
https://wiki.opendaylight.org/view/MD-SAL:Boron:Conceptual_Data_Tree
Make sure to align your thinki
19 matches
Mail list logo
