Configuration
Table of Contents
Choose Modules to Load
Floodlight can be configured to "load" different modules to accommodate different applications. Ideally, we would like to one day have Floodlight support and swap among different configurations without restart. For now, the configuration of Floodlight is done via a pair of properties files at startup. A detailed introduction to the module loading system can be found at the Module Loading System page.
In a nutshell, a user can find out or control the controller's module configuration in the following steps.
- Check src/main/resources/META-INF/services/net.floodlightcontroller.core.module.IFloodlightModule file for ALL modules compiled in the floodlight.jar binary. Note that not all compiled modules are running.
- Check src/main/resources/floodlightdefault.properties file or other customized properties file for modules selected to load/run. The file is also the place to configure certain configurable parameters at startup, such as the REST API server and web UI port (8080), the openflow port switches connect to (6653), the default timeout values, etc.
- If you are running floodlight in eclipse or by command line (java -jar floodlight.jar), by default it loads the default properties file. If you are not sure, check if the program arguments contain -cf some_properties_file.
- If you are running the floodlight VM, floodlight.jar is loaded as a service using /opt/floodlight/floodlight/configuration/floodlight.properties instead of floodlightdefault.properties.
- If you need to change the default values, stop floodlight, update the properties file, and restart.
- If you implemented any new modules, update the two files above for it to take effect.
While most floodlight applications are expected to run with the default properties, the following application(s) require a specific set of modules and thereby need a specific configuration file to run with (due to incompatibility with certain module(s)):
- OpenStack Quantum plugin works with src/main/resources/quantum.properties. See the OpenStack page.
- Forwarding v.s. StaticFlowPusher: Both of them are loaded by default, but there can be times that you would only want to load one of them for your specific application purposes. For example you'd want a fully proactively provisioned network that does not do reactive forwarding, thereby you may want to disable Forwarding and keep only StaticFlowPusher. To do this, you can edit floodlightdefault.properties to keep one or the other.
Control The Logging Level
Debug messages showing on console are helpful but at times overwhelming. Floodlight uses the org.slf4j.Logger that logs messages in different levels, which then can be controlled on a per-package or module basis. By default, floodlight shows only INFO log levels.
Terminal
To control the log level, you would pass a JVM argument as follows:
java -Dlogback.configurationFile=logback.xml -jar floodlight.jar
Eclipse
If you are running in Eclipse, you can add -Dlogback.configurationFile=logback.xml at Run -> Run/Debug Configurations -> Arguments -> VM Arguments.
A copy of logback.xml is included in the Floodlight root directory.
<configuration scan="true"> <appender name="STDOUT"> <encoder> <pattern>%level [%logger:%thread] %msg%n</pattern> </encoder> </appender> <root level="INFO"> <appender-ref ref="STDOUT" /> </root> <logger name="org" level="WARN"/> <logger name="LogService" level="WARN"/> <!-- Restlet access logging --> <logger name="net.floodlightcontroller" level="INFO"/> <logger name="net.floodlightcontroller.logging" level="WARN"/> </configuration>
In this example, the net.floodlightcontroller covers all Floodlight modules and has the logging level set as INFO, therefore any DEBUG or lower-level messages will not be shown in the console.
Log Levels
You can specify ERROR, INFO, WARN, DEBUG, and TRACE levels in logback.xml.