On Mon, Jul 9, 2018 at 1:41 PM, Tom Pantelis wrote:
>
>
> On Mon, Jul 9, 2018 at 6:29 AM, Deepthi V V
> wrote:
>
>> Hi Robert, Faseela,
>>
>> That does explain our situation.
>> But doesn't the blueprint extensions odl:rpc-implementation and
>> odl:rpc-service supposed to register and fetch the
Sam,
We are currently working on getting all the NSH related patches from jamie
in, once we get those patches in, we can see if we see these other
serialization issue.
On Mon, Jul 9, 2018 at 8:24 AM Sam Hague wrote:
> Arun, Anil,
>
> thanks for merging [1]. There are other deserialization probl
On Mon, Jul 9, 2018 at 6:29 AM, Deepthi V V
wrote:
> Hi Robert, Faseela,
>
> That does explain our situation.
> But doesn't the blueprint extensions odl:rpc-implementation and
> odl:rpc-service supposed to register and fetch the service through
> RPC-registry?
>
These were recently changed to us
Arun, Anil,
thanks for merging [1]. There are other deserialization problems failing
the tests. I filed [3] to track the issues. Can you take a look and see if
more similar changes are needed? The conntrack fields overlapping with the
nsh fields definitely makes sense as the tests are conntrack ba
Hi Robert, Faseela,
That does explain our situation.
But doesn't the blueprint extensions odl:rpc-implementation and odl:rpc-service
supposed to register and fetch the service through RPC-registry?
Thanks,
Deepthi
-Original Message-
From: Robert Varga
Sent: Monday, July 09, 2018 3:36
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 takin
Just an FYI, we were discussing on IRC why this works for netvirt still.
Netvirt uses blueprint wiring and injects the odlInterfaceRpcService, where as
sfc uses interfaceManagerRpcService =
rpcProviderRegistry.getRpcService(OdlInterfaceRpcService.class);
Robert indicated that so netvirt is bypa
JIRA raised : https://jira.opendaylight.org/browse/GENIUS-174
Jaime told the local RPC shortcut was added back on Friday, and so, he is
checking if CSIT is back to normal right now.
We will anyways track this JIRA to fix our rpc model.
Thanks,
Faseela
-Original Message-
From: Faseela K
Thanks Deepthi!
We are not using routed-rpc. This clarifies why we never hit this error before
on 3 node.
But to me, why it works for netvirt l2/l3 is still not clear.
Thanks,
Faseela
-Original Message-
From: Deepthi V V
Sent: Monday, July 09, 2018 2:19 PM
To: Faseela K ; Robert Varga
Hi Robert,
Just to clarify, IF getEgressActions RPC was a routed RPC implementation, the
issue should have been visible earlier because it would go through DOM
serialization process.
Since it is a global RPC, the call/response always happened on the same node
and because of the shortcut, there
Hello Sam
This is most likely happenning because since OVS 2.8, openflow OXM/NXM
ids that were unofficially used for the NSH fields on Yi Yang patch are
now being officially used for other different fields.
On this specific case, it is OXM field 120 in the Nicira NXM1 class,
which Yi Yang used fo
I understand that for the single node scenarios, there is a change introduced
on June 26th, due to which this will fail now.
But, are you saying for cross-node, this would have never worked even before?
We have been using the same code on 3 node, from Beryllium timeframe.
Thanks,
Faseela
-
Hi Robert,
The nicira extension used here is "resubmit to table=220" which is actually
filled by genius interfacemanager and returned to the application who invokes
the RPC. This is common for SFC and netvirt l2/l3.
Thanks,
Faseela
-Original Message-
From: Robert Varga [mailto:n...@
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: Ope
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 augmentations,
> 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.
Hello Vishal. I think is pretty common as
I merged [1]https://git.opendaylight.org/gerrit/#/c/73735/. It's very minor
patch and should not cause major trouble for jamie to rebase.
On Sun, Jul 8, 2018 at 11:03 PM Vishal Thapar wrote:
>
>
> On Mon, Jul 9, 2018 at 8:30 AM, D Arunprakash
> wrote:
>
>> Sam,
>>
>> I have seen this issue as w
Jaime, Please raise a JIRA to track this.
Robert, please let us know if we need to fix the genius data models, or we
are talking about some fix in mdsal.
It was not clear to me from the previous mail.
Also, I could not still understand why the same RPC works for netvirt l2/l3,
but not
18 matches
Mail list logo
