Re: [controller-dev] [OpenDaylight TSC] Transitioning Controller to being MRI

On 25/03/2020 23:25, Robert Varga wrote: > Hello everyone, Hello again, > The process involves three steps: > > 1) transition all of controller's downstreams to use Magnesium version > of controller artifacts > 2) remove controller from autorelease > 3) remove controller

[controller-dev] Transitioning Controller to being MRI

Hello everyone, controller committers have decided to transition the project to being release integrated many moons ago. Unfortunately execution has been postponed by various things happening -- and there are only a few points during our lifecycle when such a transition is easily doable. Since

Re: [controller-dev] [netvirt-dev] [bgpcep-dev] [OpenDaylight TSC] TSC Vote to release latest build # 326 as Sodium SR2

On 30/01/2020 20:21, Daniel De La Rosa wrote: > @Robert Varga <mailto:n...@hq.sk>  and rest of the controller team, do > you think that this > issue, ttps://jira.opendaylight.org/browse/CONTROLLER-1928 > <https://jira.opendaylight.org/browse/CONTROLLER-1928> can be solved

Re: [controller-dev] [Sodium] Failed to build hello world app into ODL

On 20/01/2020 15:53, Aniello Paolo Malinconico wrote: > Hi all, > I want to deploy an application for OpendayLight Controller. So, I am > following this > guide:  > https://docs.opendaylight.org/en/stable-sodium/developer-guide/developing-apps-on-the-opendaylight-controller.html > My steps are

Re: [controller-dev] [OpenDaylight TSC] TWS Today

On 06/01/2020 17:55, Tejas Nevrekar wrote: > Hi all, > > The agenda for today's TWS was for getting together to complete the > lighty project proposal. > > Not sure if the lighty team is ok for that today. > > Robert, can you please confirm? Sorry, there's a public holiday in Slovakia, so

Re: [controller-dev] [netconf-dev] File descriptors opened by ODL process.

On 17/12/2019 15:16, Vikram Darsi wrote: > 4. *lsof -p 31139 | wc -l    ->   503* ... the number of file descriptors open by the process. > 5. *lsof | grep 31139 | wc -l   ->    58232* > > *31139 is the ODL-controller PID* > ... the number of file descriptors open by the

Re: [controller-dev] [mdsal-dev] RetiredGenerationException : NeonSR1

On 20/11/2019 14:42, Vikram Darsi wrote: > Can someone please explain what could have gone bad and how to recover? [...] > > *Caused by: > org.opendaylight.controller.cluster.access.concepts.RetiredGenerationException: > Originating generation 0 was superseded by 8* This indicates persistence

Re: [controller-dev] Support for must constraints in the yang

Regards, Tejas On Thu, Oct 3, 2019, 11:38 PM Robert Varga <mailto:n...@hq.sk>> wrote: On 03/10/2019 19:54, Tejas Nevrekar wrote: > Hi Robert, Hello, > > Continuing here the discussion we had during the DDF when reviewing the > presentati

Re: [controller-dev] Taking controller to MRI

On 20/06/2019 14:31, Stephen Kitt wrote: > On Sat, Jun 01, 2019 at 11:33:27PM +0200, Robert Varga wrote: > [...] >> Unlike the previous MRI split-offs of odlparent/yangtools/mdsal, I do >> not believe controller is ready to also transition to strict SemVer >> rules -- we h

[controller-dev] Read(Write)Transaction.exists(InstanceIdentifier)

Hello everyone, I realized that it is not general knowledge that aside from ReadTransaction.read(InstanceIdentifier), there also is an operation to check for a particular node's existence. This operation has been available at the DOM layer since Helium, but somehow it ended up not being exposed

Re: [controller-dev] [integration-dev] [tsc][release] Configure Smart Proxy between ODL Nexus and Central

On 28/08/2019 06:36, Anil Belur wrote: > Greetings all, > > Sonatype has updated the issue that was opened Maven Central [1.] on the > missing staging repositories and made some recommendations. A large > number of staging repositories along with dup artifacts is making > Central instable.

Re: [controller-dev] Migrating inventory/topology models

[+ discuss, mdsal-dev] On 05/09/2019 19:24, Anil Vishnoi wrote: > As for the next steps, I think we need to migrate these models to > openflowplugin, where they can be maintained, as that world is the only > place that really uses them. > > As far as upstream OpenDaylight is concern

[controller-dev] Migrating inventory/topology models

Hello everyone, as it currently stands, then only projects which are using opendaylight-{inventory,topology}*.yang models are OpenFlow-specific projects (openflowplugin, genius, sfc (in sfc-genius-utils), netvirt), plus a soon-to-be-deprecated component in controller/netconf. These models have

Re: [controller-dev] Same service exposed twice with the same odl filter

On 29/07/2019 13:03, Vikram Darsi wrote: > Hi Team > >   > > Distribution : ODL Neon SR1 > >   > > Installed “odl-netconf-all” feature and ran “service:list” > >   > > [org.opendaylight.mdsal.binding.dom.codec.api.BindingCodecTreeFactory, >

Re: [controller-dev] 答复: [release] CDS serialization format in Neon SR2/Sodium

On 19/07/2019 02:22, Yi Yang (杨燚)-云服务集团 wrote: > Robert, the data in https://pantheon.tech/opendaylight-neon-sr1-sr2/ looks > amazing, can you show us those gerrit changes? How can we double check those > data you got? For Neon that's ... https://git.opendaylight.org/gerrit/#/c/82315/

Re: [controller-dev] [release] CDS serialization format in Neon SR2/Sodium

On 18/07/2019 23:41, Luis Gomez wrote: > During a cluster upgrade where you upgrade members one-by-one, how can we > control the leader does not move to a Neon SR2 member? You can explicitly move the leader via cluster-admin interface -- that way the leader movement will not be triggered by

Re: [controller-dev] [release] CDS serialization format in Neon SR2/Sodium

On 18/07/2019 20:52, Luis Gomez wrote: > > >> On Jul 18, 2019, at 10:53 AM, Robert Varga wrote: >> >> On 18/07/2019 19:14, Luis Gomez wrote: >>> Am I understanding we are introducing a non-compatible change in a Service >>> Release? >> >

Re: [controller-dev] [release] CDS serialization format in Neon SR2/Sodium

On 18/07/2019 21:24, Luis Gomez wrote: > Also, are these changes already merged in the stable branch? Yes, they are. Regards, Robert signature.asc Description: OpenPGP digital signature ___ controller-dev mailing list

Re: [controller-dev] [release] CDS serialization format in Neon SR2/Sodium

ert > > BR/Luis > > >> On Jul 18, 2019, at 8:01 AM, Robert Varga wrote: >> >> Hello everyone, >> >> this is a notice that CDS/sal-distributed-datastore will ship an >> upgraded data streaming format in Neon SR2 -- something we have not done >> since Li

[controller-dev] CDS serialization format in Neon SR2/Sodium

Hello everyone, this is a notice that CDS/sal-distributed-datastore will ship an upgraded data streaming format in Neon SR2 -- something we have not done since Lithium. This change impacts interoperability with previous versions (up to and including Neon SR1): 1) each node will upgrade its

Re: [controller-dev] Guava-28 removed CheckedFuture

On 01/07/2019 10:28, Faseela K wrote: >I will try to take it up for genius, netvirt and serviceutils. Hello Faseela, based on the direction taken in https://git.opendaylight.org/gerrit/82889, I think the best approach for genius/netvirt would be: 1) eliminate netvirt's use of

Re: [controller-dev] Guava-28 removed CheckedFuture

On 01/07/2019 11:08, Robert Varga wrote: > > On 01/07/2019 10:28, Faseela K wrote: >> Robert, >>Can you create a JIRA with the plan for deprecation and removal of >> controller APIs? > Sure. > > https://jira.opendaylight.org/browse/CONTROLLER-1902 tracks

Re: [controller-dev] Notificatoins over websockets: Making JSON notifications to go just from one node in cluster

On 01/07/2019 19:35, N Vivekanandan wrote: > Hi Team, Hello, [+neutron-dev, see below] > Can you please let us know if its possible to provide an enhanced API > from RestConfImpl, where we can request that the > datastore-change-notifications be JSON Wrapped and sent only from one > node of an

Re: [controller-dev] Guava-28 removed CheckedFuture

03 tracks removal. >I will try to take it up for genius, netvirt and serviceutils. Awesome, thanks! Regards, Robert > Thanks, > Faseela > > -Original Message----- > From: Robert Varga > Sent: Monday, July 1, 2019 1:56 PM > To: Faseela K ; rele...@lis

Re: [controller-dev] Guava-28 removed CheckedFuture

ards, Robert > Thanks, > Faseela > > -Original Message- > From: controller-dev-boun...@lists.opendaylight.org > On Behalf Of Robert Varga > Sent: Monday, July 1, 2019 1:36 PM > To: rele...@lists.opendaylight.org; odlparent-...@lists.opendaylight.org; > controlle

[controller-dev] Guava-28 removed CheckedFuture

Hello everyone, this is just a heads up that Guava 28 removed CheckedFuture: https://github.com/google/guava/releases/tag/v28.0 This means that controller-based MD-SAL APIs are now officially dead weight. While there is no immediate need to upgrade Guava in Magnesium, there is now a real need

Re: [controller-dev] 答复: Problem: ODL Neon archetype repo missing?

On 20/06/2019 18:41, Robert Varga wrote: > > Okay, with Stephen's help I was able to get the project into a > semi-reasonable state -- i.e. you can currently use 1.1.0-SNAPSHOT to > target Neon GA and 1.2.0-SNAPSHOT to target current Sodium. > > There are a couple more pat

Re: [controller-dev] Following the ODL neon archetype repo problem

On 24/06/2019 05:33, 金恺文 wrote: > Hi all, > > Thank you all very much for the quick response, now we are able to download > the archetype ;), but we found another issue: > > The Example project that we built with the version 1.1.0-SNAPSHOT archetype > has the odlparent of version 4.0.9 as

Re: [controller-dev] 答复: Problem: ODL Neon archetype repo missing?

On 20/06/2019 16:32, Abhijit Kumbhare wrote: > Sure - we can discuss it on today's call. > > On Thu, Jun 20, 2019 at 3:38 AM Robert Varga <mailto:n...@hq.sk>> wrote: > > On 20/06/2019 04:39, 金恺文 wrote: > > Hi everyone， > > Hello

Re: [controller-dev] 答复: Problem: ODL Neon archetype repo missing?

On 20/06/2019 04:39, 金恺文 wrote: > Hi everyone， Hello, > Sorry I put the wrong link in the previous mail, I followed the > neon-version guide but gave the boron-version link > >   > > So here is my question after correction: > >   > > I was trying to create an Example project following this

Re: [controller-dev] 答复: 答复: 答复: 答复: Is Read from follower shard ok and openflowplugin master must be shard leader?

On 07/06/2019 15:03, Yi Yang (杨燚)-云服务集团 wrote: > Robert, let us use inventory as an example, assume I started 127 ODL nodes, > how many leader shards can we have for it? I think it is one, so for this > case, only one node, i.e. inventory leader shard node is handling all the > inventory read and

Re: [controller-dev] 答复: 答复: 答复: Is Read from follower shard ok and openflowplugin master must be shard leader?

On 05/06/2019 02:49, Yi Yang (杨燚)-云服务集团 wrote: > Robert, thank you so much for your insightful answers, I'm wondering if we > can have a meeting to discuss this specially, last week, we discussed this in > openflowplugin weekly meeting, I believe you participated in ODL DDF and > joined

Re: [controller-dev] 答复: 答复: Is Read from follower shard ok and openflowplugin master must be shard leader?

On 04/06/2019 02:29, Yi Yang (杨燚)-云服务集团 wrote: > Robert, we're talking about scalability, can you tell us how many nodes > current akka-base clustering can support at most? Yi, I think we have vocabulary (i.e. language) discrepancy. In order to be clear: - "performance" means how fast a system

[controller-dev] 2019.06.04 Kernel Projects weekly meeting minutes

zToaEsvbXCZlvJI1LkB Content-Type: multipart/mixed; boundary="do4Z1Tgi0kc2IdOch42RWV1Ip31BI4rID"; protected-headers="v1" From: Robert Varga To: netconf-dev , infrautils-...@lists.opendaylight.org, controller-dev , mdsal-...@lists.opendaylight.org, yangtools-dev , aaa-...@lis

Re: [controller-dev] Questions Regarding Adding YANG 1.1 action support to controller

On 04/06/2019 11:52, Emmett Cox wrote: > Hi Everyone, Hey Emmett, > I'm currently working on making changes to the controller project to > allow Yang 1.1 action support. > > I've several questions regarding implementing the changes: > > 1. In regards to where sal-remoterpc-connector is

Re: [controller-dev] 答复: Is Read from follower shard ok and openflowplugin master must be shard leader?

On 31/05/2019 20:39, Anil Vishnoi wrote: > Hi Yi, > > Please see inline... > > On Thu, May 30, 2019 at 5:04 PM Yi Yang (杨燚)-云服务集团 > mailto:yangy...@inspur.com>> wrote: [trim] > # Q2. Openflowplugin clustering also has master, per its document, > only openflowplugin master node can do

Re: [controller-dev] 答复: [mdsal-dev] 答复: Is Read from follower shard ok and openflowplugin master must be shard leader?

On 03/06/2019 05:30, Yi Yang (杨燚)-云服务集团 wrote: > Robert, thank you so much for your replies. Prefix-based shard was done by > CISCO guys in 2017, Slight correction: Pantheon personnel on a contract. > it seems nobody continues to do this since then, do you plan to roll it out > in 2019 because

[controller-dev] Taking controller to MRI

Hello everyone, as noted at the DDF and https://jira.opendaylight.org/browse/TSC-207, I would like to transition the controller project to being MRI. There are multiple reasons for doing this: - it is mandated by our goverernance since day one, it's just that our processes were not up to par in

Re: [controller-dev] [mdsal-dev] 答复: Is Read from follower shard ok and openflowplugin master must be shard leader?

On 31/05/2019 02:03, Yi Yang (杨燚)-云服务集团 wrote: > Also cc dev mailing list for getting more responses. > >   > > *发件人:*Yi Yang (杨燚)-云服务集团 > *发送时间:*2019年5月30日14:08 > *收件人:*'mdsal-...@lists.opendaylight.org' > ; > 'controller-dev@lists.opendaylight.org' > ; >

[controller-dev] 2019.05.28 Kernel Projects weekly meeting minutes

zToaEsvbXCZlvJI1LkB Content-Type: multipart/mixed; boundary="do4Z1Tgi0kc2IdOch42RWV1Ip31BI4rID"; protected-headers="v1" From: Robert Varga To: netconf-dev , infrautils-...@lists.opendaylight.org, controller-dev , mdsal-...@lists.opendaylight.org, yangtools-dev , aaa-...@lis

[controller-dev] 2019.05.21 Kernel Projects weekly meeting minutes

//meetings.opendaylight.org/opendaylight-meeting/2019/kernel_projects_call/ Regards, Robert This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RmyWPuP73D1fJhzToaEsvbXCZlvJI1LkB Content-Type: multipart/mixed; boundary="do4Z1Tgi0kc2IdOch42RWV1Ip31BI4rID"; protected-headers=&qu

Re: [controller-dev] [netconf-dev] Help regarding Yang 1.1 actions

On 13/05/2019 13:49, Ajay Deep Singh wrote: > Hi Robert, Hey Ajay, > > Thank you for mail, we are going through all of them trying to understand > more on Odl. > > Regarding adding support for Yang 1.1 Action in RestConf please correct my > understanding if its wrong as explained below,

Re: [controller-dev] [release] Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore from controller

On 09/05/2019 03:25, Jenkins wrote: > Attention controller-devs, > > Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore > from controller in build > 108. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as

Re: [controller-dev] [netconf-dev] Help regarding Yang 1.1 actions

On 09/05/2019 13:27, Martin Sandberg wrote: > Hi Ajay, > >   > > Sorry, I can’t really describe the signaling sequence more than that. I > have basically no knowledge about the code, I have only tested ODL a > bit, and observed the behavior I described below. I don’t actually know > for a fact

Re: [controller-dev] org.opendaylight.controller:sal-binding-api ver. 1.9.1

On 29/04/2019 06:03, ylhs...@itri.org.tw wrote: > Hi controller-dev, > >   > > We (SNMP4SDN, self-managed project) needs the artifact > org.opendaylight.controller:sal-binding-api ver. 1.9.1 for Neon SR1. So > far in Nexus there is only ver. 1.9.0 [1], will you release ver. 1.9.1 > in Neon SR1?

Re: [controller-dev] [netconf-dev] Help regarding Yang 1.1 actions

On 25/04/2019 12:11, Emmett Cox wrote: > > > Hi everyone, Hello, > > Myself and several members of my team are investigating what changes we > would need to implement to allow restconf, mdsal and netconf to support > Yang 1.1 actions, both in a clustered and non-clustered way. YANG Tools

Re: [controller-dev] [release] Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore from controller

On 09/04/2019 03:22, Jenkins wrote: > Attention controller-devs, > > Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore > from controller in build > 78. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as well

Re: [controller-dev] Netvirt 3 node CSIT HA Tests - failure debugging

On 13/03/2019 08:38, Faseela K wrote: > +Robert > > Robert, Hello, > >     Jaya is trying the below steps in a 3 node ODL Cluster : > > 1. Take Down ODL1 and ODL2 > 1. Check all VM connectivities are intact even if 2 nodes are down > 2. Bring Up ODL1 and ODL2, sequentially as below >

Re: [controller-dev] Cluster problem

On 08/03/2019 09:05, Luis Gomez wrote: > Hi controller experts, > > I see sporadically this problem in one of our cluster deployments (Fluorine > SR1): > > 1) Operational DS gets locked in member-1 (leader of > shard-default-operational) after stopping member-2: > > 2019-03-01T14:49:05,189 |

Re: [controller-dev] Compilation errors -- mdsal

On 06/03/2019 10:01, Vikram Darsi wrote: > Hi Team > >   > > Getting compilation errors on tagged version *of mdsal project*: > > git checkout tags/release/oxygen-sr4 -b oxygen-sr4 [...] > [ERROR] Failed to execute goal > org.eclipse.xtend:xtend-maven-plugin:2.14.0:compile (default) on

Re: [controller-dev] DOMRpcImplementationNotAvailableException

On 04/03/2019 14:22, Vikram Darsi wrote: > Hi Robert > > We are using Boron-SR4 (Pretty old ☹), here is the exception: > https://pastebin.com/REP0ZuSx, Will the DOMRpcRouter/table on the problematic > node will eventually get updated with the missed RPCRegistration events? From > the logs it

Re: [controller-dev] DOMRpcImplementationNotAvailableException

On 04/03/2019 13:37, Vikram Darsi wrote: > Hi Team Hello, > 1. We have a RoutedRpc registered on one of the clustered nodes using > ClusterSingletonService. > > 2. ClusterSingletonService is up and is shown available on member-2 > (verified -> >

Re: [controller-dev] [release] Autorelease sodium-mvn35-openjdk11 failed to build sal-akka-segmented-journal from controller

On 04/03/2019 12:56, Robert Varga wrote: > > On 04/03/2019 01:51, Jenkins wrote: >> Attention controller-devs, >> >> Autorelease sodium-mvn35-openjdk11 failed to build >> sal-akka-segmented-journal from controller in build >> 27. Attached is a

Re: [controller-dev] [release] Autorelease sodium-mvn35-openjdk11 failed to build sal-akka-segmented-journal from controller

On 04/03/2019 01:51, Jenkins wrote: > Attention controller-devs, > > Autorelease sodium-mvn35-openjdk11 failed to build sal-akka-segmented-journal > from controller in build > 27. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as

Re: [controller-dev] Missing sal-binding-api ver 1.9.0

On 04/03/2019 05:14, ylhs...@itri.org.tw wrote: > Hi controller-dev folk, > >   > > Excuse me. The snmp4sdn project depends on sal-binding-api ver. > 1.9.0-SNAPSHOT [1], however for Neon release, ver. 1.9.0 would be > required, but we can’t find the 1.9.0 artifact in nexus [2] so that we > can’t

Re: [controller-dev] OFP cluster test with "tell-based"

On 26/02/2019 21:52, Luis Gomez wrote: > FYI tell-based test with latest master: > > https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-3node-gate-clustering-only-sodium/9/ > > I still see topology link information is not cleared after node/link down in > some

[controller-dev] 2019.02.26 Kernel Projects weekly meeting minutes

Hello, the minutes for this meeting are available at: > [26/02/2019 18:58:58] Meeting ended Tue Feb 26 17:58:58 2019 > UTC. Information about MeetBot at http://ci.openstack.org/meetbot.html . (v > 0.1.4) > [26/02/2019 18:58:58] Minutes: >

Re: [controller-dev] OFP cluster test with "tell-based"

On 19/02/2019 19:50, Luis Gomez wrote: > > >> On Feb 19, 2019, at 6:16 AM, Robert Varga > <mailto:n...@hq.sk>> wrote: >> >> On 19/02/2019 02:11, Luis Gomez wrote: >>> >>> >>>> On Feb 13, 2019, at 2:22 AM, Robert Varga >>

Re: [controller-dev] OFP cluster test with "tell-based"

On 19/02/2019 02:11, Luis Gomez wrote: > > >> On Feb 13, 2019, at 2:22 AM, Robert Varga wrote: >> >> On 12/02/2019 19:44, Luis Gomez wrote: >>> Hi everybody, >>> >>> FYI I have just tried OFP cluster test with "tell-based" proto

Re: [controller-dev] OFP cluster test with "tell-based"

On 12/02/2019 19:44, Luis Gomez wrote: > Hi everybody, > > FYI I have just tried OFP cluster test with "tell-based" protocol: > > https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-only-neon/180/robot-plugin/log.html.gz > > My observations: > > 1)

Re: [controller-dev] many logs about log index out-of-sync

On 09/01/2019 01:41, Tom Pantelis wrote: > > Those messages can happen if a follower gets behind the leader, > especially if it gets isolated and AppendEntries > > messages from the leader get backed up and then the follower gets > a bunch of messages quickly when it reconnects to

Re: [controller-dev] [mdsal-dev] Unknown history for purged transaction member-2-datastore-operational-fe-0-chn-12-txn-0-0, ignoring

On 26/11/2018 10:02, Faseela K wrote: > https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/rpkgenius-csit-3node-gate-only-neon/6/odl_1/odl1_karaf.log.gz Thanks. odl3 is the leader, showing: > 2018-11-26T08:54:03,409 | DEBUG | > opendaylight-cluster-data-shard-dispatcher-41 |

Re: [controller-dev] [mdsal-dev] Unknown history for purged transaction member-2-datastore-operational-fe-0-chn-12-txn-0-0, ignoring

On 23/11/2018 17:23, Faseela K wrote: > Do you still want me to reproduce the issue with the DEBUGs mentioned? Or > already identified the > Root cause? Please try to reproduced it, I have only a theory at this point, those debugs will hopefully give us a smoking gun. Thanks, Robert

Re: [controller-dev] [mdsal-dev] Unknown history for purged transaction member-2-datastore-operational-fe-0-chn-12-txn-0-0, ignoring

On 23/11/2018 16:11, Robert Varga wrote: > On 23/11/2018 15:29, Faseela K wrote: >> https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/rpkgenius-csit-3node-gate-only-neon/15/odl_2/odl2_karaf.log.gz >> >> [sandbox log, will get deleted in another 24hours, I gues

Re: [controller-dev] [mdsal-dev] Unknown history for purged transaction member-2-datastore-operational-fe-0-chn-12-txn-0-0, ignoring

On 23/11/2018 15:29, Faseela K wrote: > https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/rpkgenius-csit-3node-gate-only-neon/15/odl_2/odl2_karaf.log.gz > > [sandbox log, will get deleted in another 24hours, I guess] This looks weird, as if we lost some journal records for create, or

Re: [controller-dev] [mdsal-dev] Unknown history for purged transaction member-2-datastore-operational-fe-0-chn-12-txn-0-0, ignoring

On 23/11/2018 15:20, Faseela K wrote: > I did not understand much of it :) > But I am seeing this in genius 3 node CSIT karaf logs, Does this mean we are > doing something wrong in our datastore operations, which we have to fix? Got a pointer? Thanks, Robert signature.asc Description:

Re: [controller-dev] [mdsal-dev] Unknown history for purged transaction member-2-datastore-operational-fe-0-chn-12-txn-0-0, ignoring

On 23/11/2018 09:05, Faseela K wrote: > Hello mdsal-dev, > > Can someone please tell me when exactly this warning will come? > >   > >   > > *2018-11-23T04:37:13,831 | WARN  | > opendaylight-cluster-data-shard-dispatcher-28 | > FrontendClientMetadataBuilder    | 232 - >

[controller-dev] [yangtools-dev] MoM of today's Kernel Projects call

Hello, we had a rather longer Kernel Projects' call today, discussing some impeding changes to better support downstreams. Minutes are available at: > [20/11/2018 19:16:22] Meeting ended Tue Nov 20 18:16:22 2018 > UTC. Information about MeetBot at http://ci.openstack.org/meetbot.html . (v >

Re: [controller-dev] [mdsal-dev] new PingPongDataBroker interface for simpler annotation instead of XML based dependency injection?

On 13/11/2018 17:45, Michael Vorburger wrote: > Hello, > > In https://git.opendaylight.org/gerrit/#/c/77640/ > for https://jira.opendaylight.org/browse/OPNFLWPLUG-1046 the question > has come up how to correctly wire the ping pong DataBroker when > following the

Re: [controller-dev] [release] Autorelease oxygen failed to build sal-distributed-datastore from controller

On 08/11/2018 02:09, Jenkins wrote: > Attention controller-devs, > > Autorelease oxygen failed to build sal-distributed-datastore from controller > in build > 477. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as well as console

Re: [controller-dev] Entity ownership for non-voting member

On 07/11/2018 20:36, Ajay Lele wrote: > > > On Wed, Nov 7, 2018 at 3:58 AM Robert Varga <mailto:n...@hq.sk>> wrote: > > On 07/11/2018 02:07, Ajay Lele wrote: > > Hi Controller-devs, > > > > [0] changed EOS behavior such that a non-

Re: [controller-dev] [release] Autorelease oxygen failed to build sal-distributed-datastore from controller

On 05/11/2018 18:14, Sam Hague wrote: > Is this any way related to Lori's connection failures in the lisp IT. > Likely a stretch but they had connection issues also. Could be, if the VMs are experiencing hiccups. Then again it might have beenm a one-off... Oxygen has been just sitting there for a

Re: [controller-dev] [release] Autorelease oxygen failed to build sal-distributed-datastore from controller

On 05/11/2018 13:32, Tom Pantelis wrote: > Results : > > Failed tests:  >   ModuleShardBackendResolverTest.testRefreshBackendInfo:138 > assertion failed: timeout (3 seconds) during expectMsgClass waiting > for class >

Re: [controller-dev] Karaf error yangtool

On 01/11/2018 16:29, benamrane fouad wrote: > Hi all, Hello, > I would like to reproduce the hello world application in odl using > latest versions, but I got an error after creating the yang rpc model. > > org.apache.felix.resolver.reason.ReasonException: Unable to resolve >

Re: [controller-dev] [release] Autorelease neon failed to build sal-binding-it from controller

On 24/10/2018 09:48, Ariel Adam wrote: > Tom, any idea what this failure is? > > Karaf started in 1s. Bundle stats: 13 active, 13 total > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: > 181.838 s <<< FAILURE! - in >

Re: [controller-dev] aaa build failure in proposed topic:neon-mri ("Weather Item" TSC-132)

On 23/09/2018 17:33, Michael Vorburger wrote: > On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis > wrote: > > On Sun, Sep 23, 2018 at 7:26 AM Michael Vorburger > mailto:vorbur...@redhat.com>> wrote: > > Dear maintainers of project aaa, > >

Re: [controller-dev] [release] Autorelease neon failed to build sal-inmemory-datastore from controller

On 20/09/2018 10:34, Ariel Adam wrote: > Tom, looks like a compilation failure: > > *00:28:35* [INFO] > - > *00:28:35* [INFO] > - > *00:28:35* [ERROR] COMPILATION ERROR :

Re: [controller-dev] [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting

On 13/08/18 14:06, Anil Belur wrote: > > https://git.opendaylight.org/gerrit/#/c/75151/ > > > cool, now we just need to get autorelease to actually pass again... ;-) > I'm still, right now, seeing various failures > on  >

Re: [controller-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

On 27/07/18 13:34, Michael Vorburger wrote: > What I am wondering if such a short cut optimization has any real value, > and if it does if it shouldn't go into core MD SAL instead > of ManagedNewTransactionRunner. I do not believe it is worth the complexity it incurs. We used to shortcut

Re: [controller-dev] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

On 27/07/18 11:41, Anil Vishnoi wrote: > > My initial reaction is that such an optimization in > ManagedNewTransactionRunner is probably pointless as whatever > happens behind the scenes on a commit is surely already smart enough > by itself for a submit on an empty transaction to

Re: [controller-dev] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

On 27/07/18 13:33, Michael Vorburger wrote: > On Fri, Jul 27, 2018 at 12:21 PM Robert Varga <mailto:n...@hq.sk>> wrote: > > On 27/07/18 11:29, Michael Vorburger wrote: > > Hello, Tom, Robert, Stephen, > > > > Does commiting a tran

Re: [controller-dev] [mdsal-dev] Does commiting a transaction with no operations have any noteworthy (real life) overhead compared to cancelling it?

On 27/07/18 11:29, Michael Vorburger wrote: > Hello, Tom, Robert, Stephen, > > Does commiting a transaction with no put/.../merge/delete operations on > that Tx have any noteworthy (real life) overhead compared to cancelling it? > At the very least it requires queueing, as it needs to be

Re: [controller-dev] [release] Project docs in Fluorine

On 19/07/18 01:20, Luis Gomez wrote: > To all project committers/PTLs, > > If your project docs: Actually, we have a 3) in mdsal and controller (at least) and openflowplugin (perhaps): 3) We have some .adoc files which need conversion and proper filing :( Can somebody lend a hand to deal with

Re: [controller-dev] [release] Autorelease oxygen failed to build sal-cluster-admin-impl from controller

On 20/07/18 16:54, Daniel Farrell wrote: > > I feel like blaming infrastructure being "slow" is too easy an > excuse for issues. If the software was run in a customer production > environment I suspect telling the customer that their hardware is > too slow and is not the same

Re: [controller-dev] [release] Autorelease fluorine failed to build sal-core-compat from controller

On 19/07/18 03:04, Jenkins wrote: > Attention controller-devs, > > Autorelease fluorine failed to build sal-core-compat from controller in build > 150. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as well as console logs. > > >

[controller-dev] Understading CDS

Hello Josh, everyone, when trying to understand what CDS does and how it does it, there are concepts and technologies that must be understood -- all relating to distributed systems and state management theory. Specific topics: - Actor systems, with Akka being an implementation - Akka Clustering

Re: [controller-dev] [mdsal-dev] SystemReadyService fails, system does not work

On 03/07/18 13:43, Josh Hershberg wrote: > A number of us have seen the exception below over the past few days. > I've opened this bug to track it, anyone know anything? Missing port of CONTROLLER-1590, flushed out by controller's switch to mdsal components, already fixed. Bye, Robert

Re: [controller-dev] Serviceutils distro failure

On 26/06/18 13:40, Faseela K wrote: > Thanks a lot Michael. > > This looks like an MDSAL bug, that even if the yang modules are > separated by namespaces, there is some bug somewhere that it is not > honored properly. > >   > > I was able to change the module names in serviceutils(so that it

Re: [controller-dev] [infrautils-dev] Sharding evolution

...@lists.opendaylight.org [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga Sent: Saturday, June 09, 2018 6:25 AM To: Faseela K ; Anil Vishnoi Cc: infrautils-...@lists.opendaylight.org; controller-dev ; genius-...@lists.opendaylight.org Subject: Re: [controller-dev] [infrautils-dev

Re: [controller-dev] [infrautils-dev] Sharding evolution

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

Re: [controller-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ?

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

Re: [controller-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ?

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  https://jira.opendaylight.org/browse/GENIUS-138 to mean that > we are past the

Re: [controller-dev] yang notifications to CDS to emit interesting state/status changes

On 07/06/18 21:20, Faseela K wrote: > Yes, we are currently using EOS in such scenarios. But is there a way to > specify that I want my entity owner to be on “default-config shard leader”? > > That’s why I was asking whether the new notifications you are going to > add will help in implementing

Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches

On 05/06/18 16:28, Sam Hague wrote: > All the projects in the to: list have the ability to run genius and > netvirt csit on any patch using a gerrit comment. The job is non-voting > and only reports back status. If you do run the csit and notice a > non-success, please ping the genius and netvirt

Re: [controller-dev] Build passing for proposed topic:CONTROLLER-1802 ("Weather Item" CONTROLLER-1802)

Merged, I'll close the weather item once it's clear it does not break AR. Regards, Robert On 04/05/18 14:38, Robert Varga wrote: > Yeah, it is on my list, probably sometime on Sunday.. M > > Sent from my BlackBerry - the most secure mobile device - via the Orange > Network >

Re: [controller-dev] Build passing for proposed topic:CONTROLLER-1802 ("Weather Item" CONTROLLER-1802)

Yeah, it is on my list, probably sometime on Sunday.. MSent from my BlackBerry - the most secure mobile device - via the Orange

Re: [controller-dev] Giving Binding Specification V1 a bit of TLC

On 05/03/18 16:52, Robert Varga wrote: > Hello everyone, Hello again, as per today's TSC call, with regards to upcoming weather items from MD-SAL, here is an update to the plan: > we are still ways off of having a smooth transition plan from Binding V1 > to Binding V2 and a large body

Re: [controller-dev] Help needed in RPC input format

On 19/04/18 14:45, Gobinath . wrote: > Hi All, > >   > > I’m developing a new Routed RPC in openflowplugin project which uses > “NodeContextReference” in the input of the RPC(which have been used in > many routed rpcs too). > > Could you suggest how to frame the input body for such RPCs which

Re: [controller-dev] Web Framework Discussion (continued from Kernel Call)

On 11/04/18 17:50, Ryan Goulding wrote: > Hi All, Hello Ryan, > During the Kernel call this past Tuesday, we talked about attempting an > isolated transition of AAA restful web services from Jersey 1 to Jersey > 2.  I attempted this change yesterday, and was able to partially convert > (I just

Re: [controller-dev] [mdsal-dev] shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.opendaylight.mdsal.model:ietf-ip-2014-06-16:jar:2014.06.16.13.0-SNAPSHOT

On 11/04/18 14:54, Michael Vorburger wrote: > Hello, > > I'm hitting the error shown below on a local genius build from master - > anyone knows what that is? > > Did anything recently change re. > mdsal.model:ietf-ip-2014-06-16:jar:2014.06.16.13.0-SNAPSHOT ? It's a brand spanking new artifact

  1   2   3   >