The network configuration subsystem allows applications to inject attribute and configuration information for various network components into the models used for network representation. Examples include (but are not limited to):
The configurations may refer to a component that may or may not already exist in the network representation (i.e., the system may/may not have discovered it in the network). This implies that an application can offer hints about a yet-discovered component, as well as modify a known component’s attributes.
This subsystem likewise serves as a shim between the system’s network representation, and the means to configure it. Currently, JSON is the preferred means to describe component configurations.
DeviceId
for a network device, or a ConnectPoint
for a device port.BasicDeviceConfig
allows a device’s type and southbound driver to be set/changed.Config
subclasses implement the tunables for a subject as a set of getters and setters (attribute accessors) to JSON object constructs (ObjectNodes
). Example: An OpticalPortConfig
is defined as:
public class OpticalPortConfig extends Config<ConnectPoint> |
meaning that it manipulates the configurations associated with ConnectPoint
subjects (optical ports). Some of its attribute accessors include the port’s string and numeric names, and the number of channels that the port supports.
SubjectFactory
ties a subject to its subject key, and generates objects that represent the subject. Example: the factory that generates ConnectPoints
is instantiated as:
public static final SubjectFactory<ConnectPoint> CONNECT_POINT_SUBJECT_FACTORY = new SubjectFactory<ConnectPoint>(ConnectPoint.class, "ports") { @Override public ConnectPoint createSubject(String key) { return ConnectPoint.deviceConnectPoint(key); } }; |
meaning that the key for the JSON field containing port information is keyed on string “ports”, and the factory can create ConnectPoint
s from a “deviceId:port” string (the argument to createSubject
).
ConfigFactory
ties a subject to its config and config key, and generates Config
s. Example: The ConfigFactory for OpticalPortConfig
is defined as:
// ConfigFactory<S, C extends Config<S>> new ConfigFactory<ConnectPoint, OpticalPortConfig>(CONNECT_POINT_SUBJECT_FACTORY, OpticalPortConfig.class, "basic") { @Override public OpticalPortConfig createConfig() { return new OpticalPortConfig(); } } |
indicating that the ConfigFactory
can generate OpticalPortConfig
s, and the configuration information for a given optical port can be fetched from the subsystem’s manager using its associated subject (a ConnectPoint
in this case). In the JSON structure, the key “basic” can be used to fetch out the values set by the OpticalPortConfig
.
NetworkConfigManager
, either by adding it to BasicNetworkConfigs
which will load it when it starts up, or by manually invoking NetworkConfigManager.registerConfigFactory()
from the applicationNetworkConfigListener
The NetworkConfigWebResource
implements the REST calls for the network configuration subsystem. Its functionalities will eventually replace that of ConfigWebResource
.
The following example uses the REST API to upload a configuration file:
curl --user onos:rocks -X POST -H "Content-Type: application/json" http://192.168.56.111:8181/onos/v1/network/configuration/ -d @/tmp/cfg.json |
The above assumes a running instance at 192.168.56.111, and a configuration file at /tmp/cfg.json. They should be replaced with appropriate values.
Likewise, the user:password vaues may differ with your setup; Other common values are karaf:karaf and onos:onos.
The NetworkConfigLoader
reads JSON files from a known location and attempts to load them as network configurations.
Currently, a file named network-cfg.json is picked up from ${ONOS_ROOT}/tools/package/config/ and placed in ${KARAF_ROOT}../config/ (currently fixed) at deployment. When the remote instance boots, its network configuration loader runtime will read this file.
The Network Configuration Loader is implemented as a listener for Network Configuration events (NetworkConfigEvent
s). It attempts to use the knwon Config
s in order to generate or update entities in the network model once it is notified that the Config
s are available.