Re: [openflowplugin-dev] [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

[openflowplugin-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: [openflowplugin-dev] 答复: 答复: [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: [openflowplugin-dev] [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: [openflowplugin-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

Re: [openflowplugin-dev] [release] Autorelease sodium-mvn35-openjdk11 failed to build openflowplugin-extension-api from openflowplugin

On 25/04/2019 03:49, Jenkins wrote: > Attention openflowplugin-devs, > > Autorelease sodium-mvn35-openjdk11 failed to build > openflowplugin-extension-api from openflowplugin in build > 86. Attached is a snippet of the error message related to the > failure that we were able to automatically

Re: [openflowplugin-dev] Review openflowplugin sodium-mri patches

On 10/04/2019 10:59, SOMASHEKHAR MANOHARA JAVALAGI wrote: > Hi Robert, > Hello Somashekhar, > Openflowplugin build is passing in multipatch test run by Faseela. > > https://jenkins.opendaylight.org/sandbox/job/integration-multipatch-test-sodium/15/consoleFull > > Is openflowplugin sodium-mri

Re: [openflowplugin-dev] [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

Re: [openflowplugin-dev] [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: [openflowplugin-dev] [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: [openflowplugin-dev] [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: [openflowplugin-dev] (OPNFLWPLUG-1060) instance not able to curl metadata

On 22/01/2019 08:02, SOMASHEKHAR MANOHARA JAVALAGI wrote: > Hi Robert, > > I agree that the below mentioned log prints the events in order as per the > enqueued order while enqueuing events. > But the QueuedNotificationManager adds requests into the queue and feeds them > to the syncThreadPool

Re: [openflowplugin-dev] (OPNFLWPLUG-1060) instance not able to curl metadata

On 21/01/2019 11:28, SOMASHEKHAR MANOHARA JAVALAGI wrote: > Hi Anil Hello, > Referring to the comments of jira > https://jira.opendaylight.org/browse/OPNFLWPLUG-1060 > >   > > We have received two events for the same flow-id in below order. > > ADD event:   ADD flow with priority = 9

Re: [openflowplugin-dev] Non-compliant mail – action required, contact dm...@ericsson.se : Re: Humbly requesting review and merge of 4 changes

On 17/01/2019 14:26, Michael Vorburger wrote: > Robert, Stephen, > > can you clarify if the odlparent/mdsal version bump issue you mentioned > in the Kernel call before yesterday which you said affects distribution > is meanwhile resolved? These affect can be seen in

Re: [openflowplugin-dev] [Odlparent-dev] Karaf bootup error

On 08/01/2019 23:08, Michael Vorburger wrote: > Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to > resolve f6df3d3c-bf0e-4354-b21b-2b7fd7a538ee/0.0.0: missing requirement > [f6df3d3c-bf0e-4354-b21b-2b7fd7a538ee/0.0.0] osgi.identity; > osgi.identity=framework;

Re: [openflowplugin-dev] [OpenDaylight Discuss] [opendaylight-dev] How to get a notification over REST from a Packet-In event?

Hello, Using create-notification-stream instead of create-data-change-event-subscription in step 1) should do the trick, although I ma not sure how well if at all it's going to work. Regards, Robert On 26/11/2018 11:42, Michael Vorburger wrote: > Jose, > > Perhaps someone on the

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 15/10/2018 10:32, Stephen Kitt wrote: > Hi Robert, > > On Sun, 14 Oct 2018 20:45:31 +0200 > Robert Varga wrote: >> The question is what are we going to do about this? >> >> One option is to implement >> https://jira.opendaylight.org/browse/MDSAL-18 f

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 12/10/2018 13:58, Sam Hague wrote: > Thanks Robert for finding that. min-element/max-elements are used in > multiple other other models. Would they also have the same issue? > > What do you think about the yangtools patch going in? Should we push to > get than in rather than trying other

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 12/10/2018 15:55, Robert Varga wrote: > On 12/10/2018 14:22, Robert Varga wrote: >> On 12/10/2018 13:58, Sam Hague wrote: >>> Thanks Robert for finding that. min-element/max-elements are used in >>> multiple other other models. Would they also have the same issue? &g

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 12/10/2018 14:22, Robert Varga wrote: > On 12/10/2018 13:58, Sam Hague wrote: >> Thanks Robert for finding that. min-element/max-elements are used in >> multiple other other models. Would they also have the same issue? > That depends on the access pattern, hence it is hard to

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 12/10/2018 13:58, Sam Hague wrote: > Thanks Robert for finding that. min-element/max-elements are used in > multiple other other models. Would they also have the same issue? That depends on the access pattern, hence it is hard to say. > What do you think about the yangtools patch going in?

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 12/10/2018 11:07, Robert Varga wrote: > On 12/10/2018 10:50, Robert Varga wrote: >> On 12/10/2018 04:40, Sam Hague wrote: >>> As Jamo mentions we are hitting a new exception that we haven't seen >>> before: "VerifyException" as shown below. Any idea what th

Re: [openflowplugin-dev] [OpenDaylight TSC] CSIT status in proposed topic:neon-mri ("Weather Item" TSC-132)

On 12/10/2018 04:40, Sam Hague wrote: > As Jamo mentions we are hitting a new exception that we haven't seen > before: "VerifyException" as shown below. Any idea what that is likely > from or how to debug it? VerifyExceptions mean there is an internal logic inconsistency somewhere. I'll take a

Re: [openflowplugin-dev] [documentation] [release] Project docs in Fluorine

On 24/07/18 16:18, Thanh Ha wrote: > On Mon, Jul 23, 2018 at 8:56 PM Robert Varga <mailto:n...@hq.sk>> wrote: Hello Thanh, > On 19/07/18 01:20, Luis Gomez wrote: > > To all project committers/PTLs, > > > > If your project docs: > &

Re: [openflowplugin-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: [openflowplugin-dev] [sfc-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 10/07/18 11:56, Jaime Caamaño Ruiz wrote: > Hello Tom, Robert > >> However the serialization bypass was "broken" in the >> process. I think this explains the difference. > Are patches [1] and [2] intention to restore this bypass? > I tested [3] a multipatch build [4] with both patches and

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 09/07/18 11:55, Faseela K wrote: > Netvirt uses blueprint wiring and injects the odlInterfaceRpcService, where > as sfc uses interfaceManagerRpcService = > rpcProviderRegistry.getRpcService(OdlInterfaceRpcService.class); > > Robert indicated that so netvirt is bypassing MD-SAL, as it is

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 09/07/18 09:02, Faseela K wrote: >Also, I could not still understand why the same RPC works for netvirt > l2/l3, but not for sfc. netvirt l2/l3 is obviously not using nicira extensions, but only the actions directly defined in action-list. Regards, Robert signature.asc Description:

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 09/07/18 06:58, Faseela K wrote: > Also, what do you mean by " this code/model is broken and will not work > in an cross-node invocation and needs to be fixed." I did not understand > "cross-node" in this context, the failure is in 1 node SFC CSIT. The nicira extensions are

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 09/07/18 01:26, Robert Varga wrote: > On 07/07/18 06:20, Vishal Thapar wrote: >> possible the yang definition for this one was incorrect and some recent >> patch is now catching the violation. > output { > uses action:action-list; > } >

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 07/07/18 06:20, Vishal Thapar wrote: > possible the yang definition for this one was incorrect and some recent > patch is now catching the violation. output { uses action:action-list; } i.e. this is a separate instantiation of action-list, without mentioning any

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

On 07/07/18 06:20, Vishal Thapar wrote: > It could be specific to the action - > NxActionRegLoadNodesNodeTableFlowApplyActionsCase If no one outside of > SFC is using this action, possible the yang definition for this one was > incorrect and some recent patch is now catching the violation. I

Re: [openflowplugin-dev] [yangtools-dev] yangtools-2.0.7 released

On 26/06/18 21:45, Michael Vorburger wrote: > Question: What is the requested action here? Must all project bump now? > Does this need to be coordinated with a Managed Weather Item? Or > projects individually bump and Karaf distributions still work if > projects using different versions? Actually

Re: [openflowplugin-dev] [integration-dev] Jenkins build not triggered

On 13/06/18 13:31, Daniel Farrell wrote: > Humm, that is strange. > > This change is an example: > > https://git.opendaylight.org/gerrit/#/c/70184/ > > There was a new patchset event and your recheck keyword events. Jenkins > doesn't look particularly loaded, and I don't see any relevant >

[openflowplugin-dev] Patches needing attention

Hello OFP committers, there are two patches proposed of openflowplugin, which need to be merged to unblock progress in MD-SAL: https://git.opendaylight.org/gerrit/72314 removes use of InstanceIdentifierBuilder.toInstance(), which has been deprecated for more than three years. It is holding up

Re: [openflowplugin-dev] [release] Autorelease fluorine failed to build openflowplugin from openflowplugin

On 26/05/18 05:26, Jenkins wrote: > Attention openflowplugin-devs, > > Autorelease fluorine failed to build openflowplugin from openflowplugin in > build > 96. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as well as console logs. >

Re: [openflowplugin-dev] [release] Autorelease fluorine failed to build openflowplugin-impl from openflowplugin

On 23/05/18 05:21, Jenkins wrote: > Attention openflowplugin-devs, > > Autorelease fluorine failed to build openflowplugin-impl from openflowplugin > in build > 93. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as well as console

Re: [openflowplugin-dev] [release] openflowplugin build failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Hello Faseela, were you able to pin down the problem, or should we be reverting https://git.opendaylight.org/gerrit/#/c/71547/, which is the suspect? Thanks, Robert On 16/05/18 13:28, Faseela K wrote: > This job is stuck at the same place even now! L > >   > > *From:*Faseela K > *Sent:*

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 22/04/18 10:01, Anil Vishnoi wrote: > > If we can make Ipv4Address.equals() final, we can define it in way, > which would prevent this sort of breakage happening again -- but > that is: > 1) a restriction on how generated code can be used > 2) a relatively high-risk change

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 22/04/18 10:01, Anil Vishnoi wrote: > > To drive the argument to conclusion, though, is the analysis why things > broke -- which is because Ipv4Address.equals() uses getClass() to > determine equality. Ipv4AddressNoZone inherits that -- it's not what > Ipv4AddressNoZone type or

Re: [openflowplugin-dev] [release] IMPORTANT: Build breakage in openflowplugin due IP address NoZone changes

On 21/04/18 01:49, Robert Varga wrote: >> The weather process >> needed to have been followed - with the possibility for downstream >> projects to not accept the change for legitimate reasons. Please do so >> in the future.  >> >> The most ideal solution as

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 19/04/18 23:43, Anil Vishnoi wrote: > As I explained, it will simplify and speed things up in OFP because of > the guarantees MD-SAL can give you when you switch to no-zone types. I > think if you review the patch and the scenery of the files it touches, > there is quite a bit

Re: [openflowplugin-dev] [integration-dev] [mdsal-dev] IMPORTANT: Build breakage in openflowplugin due IP address NoZone changes

On 20/04/18 12:22, Michael Vorburger wrote: > On Thu, Apr 19, 2018 at 9:52 PM, Luis Gomez > wrote: > > FYI I just opened a grievance to remind what we did today is > exceptional and to be avoided in future: > >

Re: [openflowplugin-dev] [release] IMPORTANT: Build breakage in openflowplugin due IP address NoZone changes

On 19/04/18 20:41, Abhijit Kumbhare wrote: > Robert & Tom, > > Regardless of the merits of this particular change, I agree with Vishal > & Luis that this is a failure of communication. Yes, both Tom and I agree, this is something none of us realized and we have both agreed to improve our

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 19/04/18 21:49, Anil Vishnoi wrote: > It is not a matter of 'it could be supported', anything not defying laws > of Physics can be supported. The question is: does it make sense? can > you show an example when it would be immediately useful? > > ​ That's where i brought the point

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

Apr 19, 2018 at 11:53 AM, Robert Varga <n...@hq.sk > <mailto:n...@hq.sk>> wrote: > > On 19/04/18 20:22, Anil Vishnoi wrote: > >     All of this results in better overall user experience, I think, but > that > >     is just my opinion. > &

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 19/04/18 20:22, Anil Vishnoi wrote: > All of this results in better overall user experience, I think, but that > is just my opinion. > > ​ Yes, these are good suggestion and OFP project can take these into > account for future enhancement, but why they can't use the existing > thing in

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 19/04/18 17:58, Anil Vishnoi wrote: > > ... it is matter of what is the correct model. Given that OpenFlow has > no notion of a zone, I believe ipv4-address-no-zone is the correct type > representing OFPXMT_OFB_IPV4_*. > > ​ Please do not see it from specific project perspective,

Re: [openflowplugin-dev] [release] Build breakage in openflowplugin due IP address NoZone changes

On 19/04/18 15:14, Vishal Thapar wrote: > Hi Robert, > > Could you please take a look at tell what I need to fix this breakage? I > am still not sure why is such a basic code breaking like this. Your patch here:

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 18/04/18 21:17, Anil Vishnoi wrote: > > > On Wed, Apr 18, 2018 at 10:31 AM, Robert Varga <n...@hq.sk > <mailto:n...@hq.sk>> wrote: > > Object.equals() is required to be reflexive. Your statement "this is > not correct behavior" is based on

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

ot;inferred from anything machine-readable"?On Wed, Apr 18, 2018 at 10:07 AM, Robert Varga <n...@hq.sk> wrote: Unfortunately that cannot be inferred from anything machine-readable, so

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

...@hq.skCc: d.arunprak...@ericsson.com; integration-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; tompante...@gmail.com; openflowplugin-dev@lists.opendaylight.orgSubject: Re: Build breakage in openflowplugin due IP address NoZone changes On Wed, Apr 18, 2018 at 9:49 AM, Robert Varga &l

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

; tompante...@gmail.com; openflowplugin-dev@lists.opendaylight.orgSubject: Re: Build breakage in openflowplugin due IP address NoZone changes Hi Robert,Please see inline..On Wed, Apr 18, 2018 at 1:33 AM, Robert Varga <n...@hq.sk> wrote:On 18/04/18 08:09, D Arunprakash wrote: &

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

On 18/04/18 08:09, D Arunprakash wrote: > Hello, > > The following review in mdsal might have impacted openflowplugin > functionality. > > https://git.opendaylight.org/gerrit/#/c/70769/ Sorry about that. >

Re: [openflowplugin-dev] [OpenDaylight TSC] [release] Weather: TSC-45: MDSAL codegen breakage landing this weekend

On 02/04/18 19:27, Anil Vishnoi wrote: > I forced merge the openflowplugin patch, so i believe we are unblocked > from openflowplugin side. Thanks Anil, Most of the projects are now in the clear, I am tracking: groupbasedpolicy: needs https://git.opendaylight.org/gerrit/70258 sfc: merge #40

Re: [openflowplugin-dev] [release] Weather: TSC-45: MDSAL codegen breakage landing this weekend

On 31/03/18 16:35, Robert Varga wrote: > On 30/03/18 23:24, Robert Varga wrote: >> Hello everyone, >> >> this is a reminder that the weather item tracked at >> https://jira.opendaylight.org/browse/TSC-45 will be landing this >> Saturday, 3/31/2018 around 14:0

Re: [openflowplugin-dev] [release] Autorelease fluorine failed to build openflowplugin from openflowplugin

On 14/03/18 10:58, D Arunprakash wrote: > Hi Michael, > > We have merged one patch https://git.opendaylight.org/gerrit/#/c/69473/ > which is moving to the new toString format and will take care of the > failing TCs. > >   > > I have also raised one more patch >

Re: [openflowplugin-dev] [release] Autorelease oxygen failed to build ofoverlay-renderer from groupbasedpolicy

On 18/02/18 07:44, Jenkins wrote: > Attention groupbasedpolicy-devs, > > Autorelease oxygen failed to build ofoverlay-renderer from groupbasedpolicy > in build > 160. Attached is a snippet of the error message related to the > failure that we were able to automatically parse as well as console

Re: [openflowplugin-dev] Is "model-topology" exposed as a feature?

On 15/02/18 13:21, Faseela K wrote: > I am working on removing the inter project bundle dependencies in > openflowplugin as part of [0] > > There is a feature odl-openflowplugin-nsf-model in openflowplugin which > uses > > > > org.opendaylight.controller.model > >    

Re: [openflowplugin-dev] [yangtools-dev] Regarding ModifiedNodeDoesNotExistException

On 01/12/17 15:02, Sunil Kumar G wrote: > Hi, Hello Sunil, +openflowplugin-dev, as this relates to OFP. > I am OFP project dev and was debugging an issue where we were hitting > ModifiedNodeDoesNotExistException in > AbstractNodeContainerModificationStrategy.java method > checkTouchApplicable()

Re: [openflowplugin-dev] [mdsal-dev] Fwd: Bug 9038 - IllegalStateException: Attempted to close chain with outstanding transaction PingPongTransaction at org.opendaylight.openflowplugin.impl.device.Tra

On 24/08/17 09:39, Tomáš Slušný wrote: > > Hello Michael, > > so, according to stack trace, it looks like OpenFlowPlugin transaction > chain manager got notification that transaction chain failed, and what > we are doing then are that we create new transaction chain and close the > failed

Re: [openflowplugin-dev] [mdsal-dev] failing tests

On 09/08/17 21:44, Jamo Luhrsen wrote: > and I don't want to make any assumptions at this point, but I saw these > two patches in that list of patch differences (see the bug): > > netconf https://git.opendaylight.org/gerrit/60566 Bug 5825: Migrate > restconf to the new XML parser #2 >

Re: [openflowplugin-dev] [ovsdb-dev] [mdsal-dev] Deprecated EntityOwnershipService APIs

On 25/07/17 15:49, Sam Hague wrote: > > > EntityOwnershipService APIs are deprecated in Nitrogen release, > but we > > > > That is not true. None of the APIs are deprecated. > > > > > > I think the original controller EOS API is deprecated in favor of the > >

Re: [openflowplugin-dev] [mdsal-dev] Deprecated EntityOwnershipService APIs

On 25/07/17 12:38, Tom Pantelis wrote: > On Tue, Jul 25, 2017 at 4:12 AM, Robert Varga <n...@hq.sk > <mailto:n...@hq.sk>> wrote: > > On 13/07/17 19:14, Anil Vishnoi wrote: > > Hi mdsal-dev, > > > > EntityOwnershipService APIs

Re: [openflowplugin-dev] [mdsal-dev] Deprecated EntityOwnershipService APIs

On 13/07/17 19:14, Anil Vishnoi wrote: > Hi mdsal-dev, > > EntityOwnershipService APIs are deprecated in Nitrogen release, but we That is not true. None of the APIs are deprecated. > have following two open bug that needs to be resolved for singleton > clustering service API, otherwise project

Re: [openflowplugin-dev] Any takers for liblldp?

On 21/07/17 00:32, Sam Hague wrote: > What was the reasoning not to absorb liblldp into the openflow project? > Because lldp isn't part of openflow? That makes sense and I don't think > we will find a project as this really is it's own protocol. I do not agree with that -- LLDP is a full-blown

Re: [openflowplugin-dev] [controller-dev] FW: [Opendaylight-users] Clustering in ODL(Boron-SR3)

On 20/07/17 22:57, Xingjun Chu wrote: > I found this question on user mailing list, kind of interesting . Any > comments from controller team. > > > > Regards > > Xingjun > > > > *From:*opendaylight-users-boun...@lists.opendaylight.org >

Re: [openflowplugin-dev] [controller-dev] [sfc-dev] ODL Boron for Load Balancer Scenaio

On 17/07/17 12:52, Jaime Caamaño Ruiz wrote: > Hello Rahul > > The load balancer you reference seems to be an old ODL controller > sample application that might no longer be available. Copying > controller-dev in case anyone there can contribute. That looks like an old AD-SAL-based app. Since

[openflowplugin-dev] Any takers for liblldp?

Hello everyone, controller is hosting liblldp.jar, but it is not part of controller-published features nor is it actively maintained. As part of cleaning up the controller project, we would like to have this library removed from the controller and maintained somewhere else. Since the following

Re: [openflowplugin-dev] [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

On 28/06/17 17:58, Colin Dixon wrote: > As an aside, I'm assuming this means openflowjava will not participate > in nitrogen. Is that right? I would guess so. It also means we need to figure out something like a Termination Review process or something... Any ideas? Regards, Robert

Re: [openflowplugin-dev] [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

On 27/06/17 12:52, Tomáš Slušný wrote: > Hello Robert, > > > I can import OpenFlowJava using `git subtree` to not lose history (and I > actually have it already prepared in my local repository, because that > was first thing I tried), but then it would create Gerrit patch for each > OpenFlowJava

Re: [openflowplugin-dev] [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

On 27/06/17 12:13, Tomáš Slušný wrote: > > > https://wiki.opendaylight.org/view/Weather#OpenFlowJava_being_merged_into_OpenFlowPlugin_in_Nitrogen > > > OpenFlowJava being merged into OpenFlowPlugin in Nitrogen[edit > >

Re: [openflowplugin-dev] [controller-dev] LLDP and ODL

On 13/06/17 16:56, sothy shan wrote: > Hi, > I am playing with ODL with minnet on LLDP aspect. > I observed messge passing between ODL and mininet (OVS). > At OVS, I didnt finy rules get installed to direct LLDP packets to > controller. > Normally, ODL should install the openflow rules to forward

Re: [openflowplugin-dev] [integration-dev] Many OVS connects/disconnects causing high load, disconnects, failure

On 09/06/17 14:05, Tim Irnich wrote: > Al I think you’re hitting the nail on the head here. We were thinking > the same, giving heartbeat messages priority over other message > processing should prevent this cascading effect we have seen. Not sure > if the current framework allows this though… If

Re: [openflowplugin-dev] [OpenDaylight TSC] [VOTE} Tomas Slusny as a committer on OpenFlow Plugin

+1 Bye, Robert On 13/04/17 17:55, Colin Dixon wrote: > See below and please vote +1,0,-1. > > Thanks, > --Colin > > On Tue, Apr 11, 2017 at 12:56 PM, Abhijit Kumbhare > > wrote: > > Hello TSC, > > On behalf of the OpenFlow Plugin

Re: [openflowplugin-dev] [release] karaf4

On 13/04/17 14:24, Miroslav Macko wrote: > 2017-04-13 13:49:18,876 | INFO | pool-2-thread-1 | FeaturesServiceImpl > | 7 - org.apache.karaf.features.core - 4.0.9 | Stopping > bundles: > 2017-04-13 13:49:18,877 | INFO | pool-2-thread-1 | FeaturesServiceImpl > | 7 -

Re: [openflowplugin-dev] [mdsal-dev] lmax cpu 100% question

On 27/03/17 03:30, xiaohongaifeng wrote: > hello all: > I use odl controller to do some test, after I install all feature, > I use mininet simulate some hosts(230 hosts) and 3 switches, I found my > odl controller does not work, and I see the odl java process take > up nearly 100% cpu, and I

Re: [openflowplugin-dev] [integration-dev] [opendaylight-dev] netvirt 3node carbon csit in trouble

On 23/03/17 15:07, Robert Varga wrote: > I finally managed to find > some logs at > https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-3node-openstack-newton-nodl-v2-upstream-transparent-carbon/376/archives/. > The sheer amount of exceptions makes reasoning about what is goi

Re: [openflowplugin-dev] [integration-dev] [opendaylight-dev] netvirt 3node carbon csit in trouble

On 23/03/17 15:34, Tom Pantelis wrote: > https://bugs.opendaylight.org/show_bug.cgi?id=8027 already was created > for this. ShardTransaction.closeTransaction is directly calling abort in > the Shard which violates actor encapsulation. Okay, this explains the weirdness I observed in other logs --

Re: [openflowplugin-dev] [integration-dev] [opendaylight-dev] netvirt 3node carbon csit in trouble

On 23/03/17 15:07, Robert Varga wrote: > I finally managed to find > some logs at > https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-3node-openstack-newton-nodl-v2-upstream-transparent-carbon/376/archives/. > The sheer amount of exceptions makes reasoning about w

Re: [openflowplugin-dev] [integration-dev] [opendaylight-dev] netvirt 3node carbon csit in trouble

On 23/03/17 15:07, Robert Varga wrote: > I finally managed to find > some logs at > https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-3node-openstack-newton-nodl-v2-upstream-transparent-carbon/376/archives/. > The sheer amount of exceptions makes reasoning about what is goi

Re: [openflowplugin-dev] [integration-dev] [opendaylight-dev] netvirt 3node carbon csit in trouble

On 23/03/17 15:07, Robert Varga wrote: > I finally managed to find > some logs at > https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-3node-openstack-newton-nodl-v2-upstream-transparent-carbon/376/archives/. > The sheer amount of exceptions makes reasoning about what is goi

Re: [openflowplugin-dev] [integration-dev] [opendaylight-dev] netvirt 3node carbon csit in trouble

On 22/03/17 18:01, Luis Gomez wrote: > Here [1], it is suggested to give 24 hours for upstream project to analyze > regression and provide fix or revert. So given you notified yesterday 2:15 PM > PST, I would expect either a fix or a revet no later than this afternoon. > > [1] >

Re: [openflowplugin-dev] [controller-dev] Barrier request/reply - SalFlowRpc

openflow question: +openflowplugin-dev. On 02/01/2017 05:43 PM, Muthukrishnan Thangasamy wrote: > Dear Team , > > > > Whenever I push flow through salFlowRpc ( from NorthBound ) , Barrier > request and response immediately followed after flow push to ensure > flows are written in the switch. >

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

On 01/19/2017 01:37 PM, Tom Pantelis wrote: > yes - it looks like RpcServiceMetadata can't find the DOMRpcService. All > the DOM services are instantiated/registered > in > controller/opendaylight/md-sal/sal-dom-broker/src/main/resources/org/opendaylight/blueprint/dom-broker.xml > ​ So this

Re: [openflowplugin-dev] [mdsal-dev] OVS connection problems

On 12/14/2016 09:29 AM, Sela, Guy wrote: > 2016-12-14 10:12:20,183 | ERROR | ult-dispatcher-4 | > SimpleShardDataTreeCohort| 176 - > org.opendaylight.controller.sal-distributed-datastore - 1.4.2.SNAPSHOT | > Transaction member-1-datastore-operational-fe-0-chn-1-txn-0 failed to > prepare >

Re: [openflowplugin-dev] [yangtools-dev] REST performance regression

On 11/21/2016 06:06 PM, Luis Gomez wrote: > > Thanks for the quick turnaround, it seems it is fixed now: > > https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-config-performance-only-boron/plot/Flow%20Config%20Performance/ >

Re: [openflowplugin-dev] [release] [WEATHER] - topology id in openflowplugin

On 11/10/2016 07:40 PM, Ryan Goulding wrote: > What they should be doing is probably far from what they actually are > doing. Is this expectation actually written anywhere? Otherwise, how > are consumers supposed to know? Lets not punish people for trying to > use our product. I agree on the

Re: [openflowplugin-dev] [release] [WEATHER] - topology id in openflowplugin

Can we instantiate a proxy via topoprocessing to keep compatibility? Bye, Robert On 11/10/2016 04:22 PM, Abhijit Kumbhare wrote: > Yes - I agree with Colin. > > On Thu, Nov 10, 2016 at 7:16 AM, Colin Dixon > wrote: > > I've commented on

Re: [openflowplugin-dev] [release] [autorelease][usc] Carbon Autorelease Jobs are failing due to compilation errors.

On 10/14/2016 01:18 PM, Robert Varga wrote: > https://git.opendaylight.org/gerrit/46944 adjusts for the change, > alternatively we can revert the version bump. The distribution check job has failed on timeout which seems to be coming from openflow plugin: org.opendaylight.controller.

Re: [openflowplugin-dev] [controller-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

Re: [openflowplugin-dev] [yangtools-dev] verify job failing for stable/boron

On 08/31/2016 03:20 AM, Anil Vishnoi wrote: > Hi, > > Looks like after merging following yangtools patch, verify job is > failing for ovsdb project > > https://git.opendaylight.org/gerrit/#/c/44614/ Sorry about that, I forgot to re-merge mdsal, should be fixed now. Bye, Robert signature.asc

Re: [openflowplugin-dev] [release] [netvirt-dev] OFP YANG model change has broken some project builds on master

On 08/03/2016 10:16 PM, Anil Vishnoi wrote: > BTW do we have ODL wise release note that is used to mention all the API > changes ? I thought that was under the scope of the project and project > mention all the API changes happened in the release. isn't it the case? It is, but if the project

Re: [openflowplugin-dev] [OpenDaylight Discuss] Regarding data movement from config data store to switches and then to operational data store

On 07/12/2016 01:03 PM, NITHIN V wrote: > Hi All, > > I have tried to develop a multicast module as a sub project under the > l2switch and the module is able to insert appropriate flows to the > config data store, but the data is not moving to the switches. I am > compiling the l2switch project

Re: [openflowplugin-dev] [opendaylight-dev] [releng] More automated testing, please! And make it gating.

On 07/06/2016 07:28 PM, Andrew Grimberg wrote: > Secondly, committers would _lose_ the verify rights as they would become > completely managed by Jenkins. The values would change from -1 .. +1 to > become -1 .. +2 > > Thirdly, committers would _lose_ the submit right. This would be > completely

Re: [openflowplugin-dev] [release] Weather report: changing default design for OpenFlow plugin on master branch to Li design from He design by June 21

On 06/22/2016 05:59 PM, Abhijit Kumbhare wrote: > We have merged the change - so now we are default Li design! Thanks to everyone who has contributed their time in the past year to make this a reality :) Bye, Robert signature.asc Description: OpenPGP digital signature

Re: [openflowplugin-dev] [release] openflowplugin-verify-boron builds are failing

On 06/14/2016 04:33 PM, Vishal Thapar wrote: > Getting the same error in netvirt too: > > > > https://jenkins.opendaylight.org/releng/job/netvirt-verify-boron/270/jdk=openjdk8,nodes=dynamic_verify/console Nexus is having issues (again). Bye, Robert signature.asc Description: OpenPGP

Re: [openflowplugin-dev] [nic-dev] [release] [didm-dev] OFP getTableFeature() breakage in nic and didm

On 05/25/2016 07:43 AM, Anil Vishnoi wrote: > So looks like these yang model changes Hello, This will need to be release-noted, as it is a change in public API. Bye, Robert signature.asc Description: OpenPGP digital signature ___ openflowplugin-dev

Re: [openflowplugin-dev] [release] [didm-dev] [nic-dev] OFP getTableFeature() breakage in nic and didm

On 05/24/2016 04:50 PM, Thanh Ha wrote: > I believe NIC boron is also broke due to this same issue so adding them > to this thread. Yes, it has not published artifacts for a long time, those got purged and now we cannot publish new ones via remerge. Bye, Robert signature.asc Description:

Re: [openflowplugin-dev] [OpenDaylight Discuss] Important: Inventory model migration proposal (instead of inventory to topology model migration)

On 05/02/2016 11:52 PM, Abhijit Kumbhare wrote: > Hi folks, > [snip] > This will require some change by the dependent projects (some > modifications in the dependency declaration in the pom files) - however > it will be less change than a complete migration to the topology model. > *If you have

  1   2   >