The goal is to clean up the interfaces a little bit in preparation for
a major RouteService refactoring that is coming.
Change-Id: Ifbde9a507dd0dc3cddcd7fa1c02c426dad386e5f
This change is needed to let appications specify tables in flow rules
using indentifiers that are not numeric, e.g. using table names as in a
P4 program.
This change deprecates the FlowRule.tableId() method, in favor of
FlowRule.table(), which returns an object of type TableId. However, it
does not deprecate the .forTable(int tableId) builder method, since it
is used extensivelly in the ONOS code base and from external
applications.
Deprecating FlowRule.tableId() does not seem to be such a painful move
since it is used less frequently, e.g. only 22 usages in the ONOS tree.
Change-Id: Idaaaab53d0c1e20a1f9c7de84de09ec3a42648b5
- New class for action runtime parameter and its identifier
- PiAction builder
- Various indentifier builders
Change-Id: I265f71c868c21dbbbe633622b0c4330712f5a5ad
- BundleStitcherTest now working!
- Expand aliases in from lines.
- Added unit tests for parsing of from lines.
Change-Id: I65d343f1283fd60f46879431c37299c6ecd5a36e
- renamed script to eliminate the .py extension
- fixed interpreter name
- fixed a bug where a PUT operation returned an invalid respose
- broke up handling of the '/' URI into separate methods
- fixed typos in comments
- made script executable
- added http status codes to returned errors
Change-Id: I0809dcd912db15403b487a9ade31e8928e9b12e0
- WIP: LionService (client-side) is still faked out
- Need to request localized data from server still.
Change-Id: I2d846214343d3574ad246bfe50ef76dc89678b23
ONOS-6326: Add friendly names to hosts.
- PLENTY more YakShaving:
* some cleanup of the device view handler
* introduce navPath field to PropertyPanel
* introduce "-" name annotation to represent "use default"
* (and more...)
Change-Id: I2afc0f1f29c726b90e97e492527edde2d1345ece
At present, we have to use requestPackets to trigger adding packet processor for virtual network and use cancelPackets to trigger removing the packet process for the virtual network.
But if we call cancelPackets more then one time in the deactivate() method when the application is deactivated, if will throw a NullPoint exception.
Furthermore, if a user does not requestPackets() in the application, the packet processor will never be added.
It may be a confusing trouble for a tenant user.
As a result, I think the packet processor should be created when the virtual network is added and be removed when no virtual network exists.
Soultions:
Listen to the network event to add and remove packet processor for virtual network.
Change-Id: I583d453219bef2f271b4a1e96f9869a28b4f0250
