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 looks like a BP/feature inconsistency at least in case of failing #50488. Thinking about this a bit more, there is odl:rpc-service-related change introduced by 50488 -- and it points to missing downstream wiring (or a deadlock). Currently sal-remoterpc-connector registers a wildcard (bound to all contexts) RPC implementation for all routed RPCs it sees in SchemaContext -- which means that odl:rpc-service will be satisfied even though there is no real implementation for it, just a proxy for remoting. With 50488 that is gone, i.e. odl:rpc-service will be satisfied only when a real implementation (local or remote) is actually registered. For lldp-speaker failure (https://jenkins.opendaylight.org/releng//job/controller-distribution-check-carbon/1441/), this is a bit complicated: it requires that PacketProcessingService be registered and then it exports OperationalStatusChangeService via odl:rpc-implementation. I think this supports dynamic service instantiation of a pipeline -- an OperationStatusChangeService is published for each connected switch. Is that really the intent? If so, odl:rpc-service and odl:rpc-implementation in lldp-speaker.xml need to be interpreted as being dynamic and they must not contribute to the set of required resources needed for lldp-speaker activation. Tom, OFP team: what are thoughts on this? Thanks, Robert (off to look around the BP extension)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
