Operating System: Mac OS
Platform: PC

Requirement:-
The feature Port Config will enable the client to access the port descriptions of all the ports of a node. Since the associated OFPMP_PORT_DESCRIPTION is a multipart request, we need to cache the intermittent results (received as notifications from multipart response) and deliver the PortDescription/Config response to the client.
As part of collecting all multipart response notifications for port description we would need to :

• have some cache mechanism as currently all transformation code is stateless
• will be responsible for assigning responses based on xid and type
• will be responsible for timeouting of whole rpc if device disconnects or slows down

Openflowplugin/OFJava:
requestPorts() in ConnectionConductor currently gets the PortDescription after handshake.
In order to provide an RPC we might need to leverage this.

I am interested to work on this bug, please let me know about desired implementation and details for this enhancement.

I believe we don't need caching of all the multipart response messages, because each multipart response message payload contains data that can make sense without rest of the multipart messages. E.g if a switch has 40 ports (1 to 40) and it decides that it will send the response in 4 multipart message,then it will pack port_description of 10 ports and send in each multipart response. So whenever controller receives the port description multipart message it can decode the port description of these 10 ports and augment it to their respective port/node connector location in the operational data store.

Subhash:
If you are still interested in working on this enhancement, you can start with
1) Read openflow spec to understand the openflow multipart messages
2) Understand the port description multipart request message and what all data you can get in response to this multipart request.
3) Look at the translator java files in openflowplugin project
openflowplugin/src/main/java/org/opendaylight/openflowplugin/openflow/md/core/translator

It will give you idea about high level control flow and clues on how to hack it.

Thanks
Anil

subhash kumar singh and Abhijit, I will take this defect and work on. Please let me know if you/someone working on this already.

Hope this defect is for Beryllium release.

I dont understand the following part

"In order to provide an RPC we might need to leverage this."

Kamal Rameshan,
Could you explain this?

Thanks,
Hari

Provided RPC service. Please check port-config from yang-ui for reference. Provided this service for both He and Li code.

Changes ref:
https://git.opendaylight.org/gerrit/#/c/24568/

Provided RPC service. Please check the rest api under port-config module from yang-ui for reference. Provided this service for both He and Li code.

Changes ref:
https://git.opendaylight.org/gerrit/#/c/24568/

(In reply to Hariharan Sethuraman from comment #7)
> Changes ref:
> https://git.opendaylight.org/gerrit/#/c/24568/

This API dont return the port-config, it updates the port-config in the datastore. Since we are re-using existing helper method for this multipart request, which ultimately updates the datastore. So the consumer should check the returned transaction activity is finished and then retrieve the port-description from the datastore directly.

(In reply to Hariharan Sethuraman from comment #8)
> Provided RPC service. Please check the rest api under port-config module
> from yang-ui for reference. Provided this service for both He and Li code.
>
> Changes ref:
> https://git.opendaylight.org/gerrit/#/c/24568/
>
> (In reply to Hariharan Sethuraman from comment #7)
> > Changes ref:
> > https://git.opendaylight.org/gerrit/#/c/24568/
>
> This API dont return the port-config, it updates the port-config in the
> datastore. Since we are re-using existing helper method for this multipart
> request, which ultimately updates the datastore. So the consumer should
> check the returned transaction activity is finished and then retrieve the
> port-description from the datastore directly.

Removed the changes from Li codebase as commented by Michal. Refer code review comments in git.

Will be abandoning the changes and close the defect before this week end. Before that please let me know if you have any concerns.

Code abandoned. We cant provide RPC despite of the fact that this RPC can be used to update port-configuration on demand. If we provide RPC, it turns out to have an unwanted effect in scenario when port flaps while multipart reply being constructed, this leeway the port status out of sync.