Resubmitted with source code synchronized. Added integration test for hosttracker, split switchmanager into api and implementation bundles. Change-Id: I04d5d89562316cafa89a5ee46e08eb724733711a Signed-off-by: taochang <taochang@cisco.com>
- Plugin sends Barrier msg every 100 async msgs (configurable thru config.ini: of.barrierMessagePriorCount) - SAL/plugin provide service to send Barrier message on demand. FM/application should invoke it explictly for sync purpose. - LLDP interval is set to 5 mins (configurable thru config.ini: of.discoveryInterval) - LLDP timeout is set to 1 min (configurable thru config.ini: of.discoveryTimeout). Retry 2 times. - Switch liveness timeout is set to 60.5 sec (configurable thru config.ini: of.switchLivenessTimeout) - SAL generates Request ID and passes it down to the plugin (IPluginInFlowProgrammerService: addFlowAsync(Node node, Flow flow, long rid), modifyFlowAsync(), deleteFlowAsync()) - STATS_REPLY timeout is configurable now thru config.ini of.messageResponseTimer - Same priority messages are in FIFO manner - Fix invalid ChassisID in LLDP packet - Debugging messages - Code style formatting Signed-off-by: Jason Ye <yisye@cisco.com>
Redirecting Caught and Uncaught Exceptions to OSGI Console and Log File The existing mechanism int the Controller allows the exceptions to be printed only the console. This applies to both caught and uncaught exception. If the console buffer is not too large and gets overwritten or gets cleared, there is no way for the user to know what exceptions occurred. This commit implements a new mechanism by which both types of exceptions will get printed on the console as well as logged to the file. Signed-off-by: Maurice Qureshi <maquresh@cisco.com>
- If a port is already under OF control and then hw LLDP transmit is enabled on it, controller should discard the hw LLDP packet. - When we change the name of the Production switch, stale entries should be removed. - Added Backend APIs to add/delete/get user link configs - Northbound REST APIs to GET/POST/DELETE user link configs - Endpoint connected as Production Switch to OF port. If the system-name TLV exists in the hw LLDP packet, it should be used for display. - Some misc osgi debugging commands. Signed-off-by: Jason Ye <yisye@cisco.com>
ISSUE: After controller restart, proactive flows are not installed This is because of an incongruence between Devices.web and SwitchManagerImpl code, where the former only consider the Node.nodeID string form and the latter expects the full Node string form. CHANGE: Have Devices.web passing Node.toString() form to front-end Change-Id: I04443178099f151b37b76d4f8a5e41cee64f5ecb Signed-off-by: Alessandro Boch <aboch@cisco.com>
ISSUE Opendaylight controller to get node description from OF description statistics datapath description field CHANGE - Switch Mgr to expose a getNodeDescription() method which returns the description configured by user if any, otherwise the one learnt from the proto plugin - Web bunldes to make use of the above api (Currently they are ignoring the info learnt by the plugin) - OFStatisticsManager to implement a IStatistics interface for informing listeners that the description statistics info has been refreshed - Removing current logic where OFStatisticsManager was explicitely invoking the description property update on InventoryService through IOFInventoryService - Removed logic where InventoryServiceShim queries OFStatisticsManager about node description as information is not available at that time and IStatisticsListener updates will serve same purpose - Removing statistics request timeouts from OFStatisticsManager as the timeout is compeltely handled by core.internal.StatisticsCollector Change-Id: I0d2941d3012ca6dc77a386570dbbd8e5c7832a03 Signed-off-by: Alessandro Boch <aboch@cisco.com>
ISSUE Currently ForwardingRulesManager installs the proactive mode flows through the static flow configuration path. This allows these controller generated flows to be listed in the flow programmer UI. The drawback of this approach is that now the proactive flows are saved to FRM startup configuration, when user saves the config. So when FRM boots up, it will program the proactive flows on the switch whenever the switch connects to the controller, regardless of the actual switch forwarding mode configured on switch mgr. This is not correct as the notion of proactive forwarding mode associated to a switch is controlled by switch manager, through sm UI. The trigger to install the proactive flows should come from switch manager, FRM should not save these internal generated flows to its startup config, nor program them on its own. CHANGES 1) On FRM config save, the internal generated static flows will not be added to the list that will be actually saved. 2) In Switch Mgr, when the switch connects, while reading the respective switch configuration (if any) the mode is learnt. If it is set to proactive, the mode change event is being played. 3) When a switch disconnect, FRM has to remove the internal static flow configurations for that switch. 4) Switch Mgr isSpecial method to correctly report special node conenctor (method should be provided by NodeConnector class in future). 5) Adding the startup directory to the distribution to allow write/read of startup configuration files. 6) Have FlowConfig class to expose a method to retrieve the configured forwarding mode, so that internal coding is hidden to clients. Signed-off-by: aboch <aboch@cisco.com> Change-Id: Id628042b7d656d95ace87a1e72c13f2950e6795c Signed-off-by: aboch <aboch@cisco.com>
Refactoring SubnetConfig: -Use NetUtils IP validation methods instead of own regex and duplicate method -Remove unused method getFieldsNames() Change-Id: I6efc16a0fad39c622411e93cf5a3e4d377678de7 Signed-off-by: Kalvin Hom <kahom@cisco.com>
OpenDaylight Controller functional modules. Change-Id: I1cd6668738099e8db3cfe83f812a92c922ced38c Signed-off-by: Madhu Venugopal <vmadhu@cisco.com>