I added the wait to avoid heisenbugs where the app expects the RPC impl to be there on startup, i.e. it can't startup and will fail if the impl isn't present. But if there are apps which don't require this, i.e. the impl is registered dynamically based on some event, then we can add a flag to elide the wait. ________________________________________ From: Robert Varga <n...@hq.sk> Sent: Thursday, January 19, 2017 8:24 AM To: Tom Pantelis; Michael Vorburger; controller-dev Cc: genius-...@lists.opendaylight.org; openflowplugin-...@lists.opendaylight.org Subject: Re: 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 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) _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
