Jump to: navigation, search

OpenDaylight Controller:Config:Examples:Threadpool

Configuration example of thread pools using yangcli-pro

For a yangcli-pro example, see the user guide

Configuration example of thread pools using telnet

It is also possible to manipulate the configuration without the yuma cli. With just a telnet or ssh connection, it is possible to send the plain text containing netconf rpcs encoded in the xml format and achieve the same results as with yuma cli.

This example reproduces the configuration of a threadpool and a threadfactory from the previous example using just a telnet connection. We can also use ssh connection, with the netconf rpcs sending procedure remaining the same. For detailed information about initial configuration for the controller as well as the configuration process, see the example using yuma cli.

Connecting to plaintext TCP socket

Open a telnet connection:

telnet 127.0.0.1 8383

Open an ssh connection:

ssh netconf@127.0.0.1 -p 1830 -s netconf

Password for user netconf is : netconf

The separator for messages is:

]]>]]>

Every message needs end with these 6 characters.

You should see a hello message from the server:

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:exi:1.0</capability>
<capability>urn:opendaylight:l2:types?module=opendaylight-l2-types&amp;revision=2013-08-27</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup?module=threadgroup&amp;revision=2013-11-07</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding?module=opendaylight-md-sal-binding&amp;revision=2013-10-28</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:threadpool?module=threadpool&amp;revision=2013-04-09</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:config?module=config&amp;revision=2013-04-05</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&amp;revision=2010-10-04</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor?module=netty-event-executor&amp;revision=2013-11-12</capability>
<capability>urn:ietf:params:xml:ns:yang:rpc-context?module=rpc-context&amp;revision=2013-06-17</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl?module=opendaylight-sal-binding-broker-impl&amp;revision=2013-10-28</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:netty:timer?module=netty-timer&amp;revision=2013-11-19</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2010-09-24</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl?module=threadpool-impl&amp;revision=2013-04-05</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2010-09-24</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:logback:config?module=config-logging&amp;revision=2013-07-16</capability>
<capability>urn:opendaylight:params:xml:ns:yang:iana?module=iana&amp;revision=2013-08-16</capability>
<capability>urn:opendaylight:yang:extension:yang-ext?module=yang-ext&amp;revision=2013-07-09</capability>
<capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&amp;revision=2013-11-19</capability>
<capability>http://netconfcentral.org/ns/toaster?module=toaster&amp;revision=2009-11-20</capability>
<capability>urn:opendaylight:params:xml:ns:yang:ieee754?module=ieee754&amp;revision=2013-08-19</capability>
<capability>urn:opendaylight:params:xml:ns:yang:nps-concepts?module=nps-concepts&amp;revision=2013-09-30</capability>
</capabilities>
 
<session-id>4</session-id>
</hello>
]]>]]>

You, as the client, need to respond with a hello message:

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
    </capabilities>
</hello>
]]>]]>

There is no response to the hello message, but the session is already established.

Configuring threadfactory

Xml equivalent to get-config source=running:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
    <get-config>
        <source>
            <running/>
        </source>
    </get-config>
</rpc>
]]>]]>

Response containing the current configuration:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
	<data>
		<modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
			<module>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-broker-impl-singleton</type>
				<name>binding-broker-singleton</name>
			</module>
		</modules>
		<services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
			<service>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
				<instance>
					<name>ref_binding-broker-singleton</name>
					<provider>/modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']</provider>
				</instance>
			</service>
		</services>
	</data>
</rpc-reply>]]>]]>

To create an instance of threadfactory-naming with the name threadfactory-bgp and the attribute name-prefix set to bgp, send message:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<edit-config>
		<target>
			<candidate/>
		</target>
		<default-operation>merge</default-operation>
		<config>
			<modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
				<module xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
					<name>threadfactory-bgp</name>
					<type xmlns:th-java="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">th-java:threadfactory-naming</type>
					<name-prefix xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">bgp</name-prefix>
				</module>
			</modules>
		</config>
	</edit-config>
</rpc>]]>]]>

To commit the threadfactory instance, send a commit message:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<commit/>
</rpc>]]>]]>

The Netconf endpoint should respond with ok to edit-config as well as the commit message:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
        <ok/>
</rpc-reply>]]>]]>

Now the response to the get-config message (same as the first message sent in this example) should contain the commited instance of threadfactory-naming:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
	<data>
		<modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
			<module>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-broker-impl-singleton</type>
				<name>binding-broker-singleton</name>
			</module>
 
			<module>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">prefix:threadfactory-naming</type>
				<name>threadfactory-bgp</name>
				<name-prefix xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">bgp</name-prefix>
			</module>
		</modules>
 
		<services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
			<service>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadfactory</type>
				<instance>
					<name>ref_threadfactory-bgp</name>
					<provider>/modules/module[type='threadfactory-naming'][name='threadfactory-bgp']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
				<instance>
					<name>ref_binding-broker-singleton</name>
					<provider>/modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']</provider>
				</instance>
			</service>
		</services>
	</data>
</rpc-reply>]]>]]>

Configuring fixed threadpool

To create an instance of threadpool-fixed , with the same configuration and the same dependency as before, we need to send the following message:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<edit-config>
		<target>
			<candidate/>
		</target>
		<default-operation>merge</default-operation>
		<config>
			<modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
				<module xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
					<name>bgp-threadpool</name>
					<type xmlns:th-java="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">th-java:threadpool-fixed</type>
					<max-thread-count xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">100</max-thread-count>
					<threadFactory xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">
						<type xmlns:th="urn:opendaylight:params:xml:ns:yang:controller:threadpool">th:threadfactory</type>
						<name>ref_th-bgp</name>
					</threadFactory>
				</module>
			</modules>
 
			<services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
			<service>
				<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadfactory</type>
				<instance>
					<name>ref_th-bgp</name>
					<provider>/modules/module[type='threadfactory-naming'][name='threadfactory-bgp']</provider>
				</instance>
			</service>
		</services>
		</config>
	</edit-config>
</rpc>]]>]]>

Notice the services tag. If an instance is to be referenced as a dependency by another module, it needs to be placed under this tag as a service instance with a unique reference name. Tag provider points to a unique instance that is already present in the config subsystem, or is created within the current edit-config operation. Tag name contains the reference name that can be referenced by other modules to create a dependency. In this case, a new instance of threadpool uses this reference in its configuration under threadFactory tag).

You should get an ok response again, and the configuration subsystem will inject the dependency into the threadpool. Now you can commit the configuration (ok response once more) and the process is finished. The config subsystem is now in the same state as it was at the end of the previous example.