Versions Compared

Old Version 64

changes.mady.by.user Amir Shehata

Saved on

compared with

New Version 65

changes.mady.by.user Amir Shehata

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

PolicyTest case
Network Rule

Add and verify local network policy.

Code Block
peer1_address = argv[1]
peer2_address = argv[2]
net = argv[3]
intf = argv[4]
net2 = argv[5]
intf2 = argv[6]

peer1 = make_nid(peer1_address, net)

net_cfg = [{'net' = net, 'intf' = intf}, {'net' = net2, 'intf' = intf2}]
add_verify_net(net_cfg, peer1)
add_verify_policy(net, 0, peer1)

Verify traffic goes over the network with the highest priority

Code Block
# script should grab its input from user (can be automated)
peer1_address = argv[1]
peer2_address = argv[2]
net = argv[3]
intf = argv[4]
net2 = argv[5]
intf2 = argv[6]

net_cfg = [{'net' = net, 'intf' = intf}, {'net' = net2, 'intf' = intf2}]
add_verify_net(net_cfg, peer1)
add_verify_policy(net, 0, peer1)

peer1 = make_nid(peer1_address, net)
peer2 = make_nid(peer2_address, net)
add_verify_net(net_cfg, peer2)
add_verify_policy(net, 0, peer2)
stats1 = get_traffic_stats(peer1)
generate_traffic(peer1, peer2)
stats2 = get_traffic_stats(peer1)
verify_traffic_on(stats1, stats2, net)

Verify traffic goes over the network with the healthiest local NI even though it might not be set to highest priority

Delete local network policy and verify it has been deleted

Verify traffic returns to normal pattern when network policy is deleted

Error handling: Add policy for non-existent network

Add and verify a remote network policy. IE messages will need to be routed to that network

Verify traffic is routed to the remote network with the highest priority

Verify traffic is routed to another available network given the highest priority remote network is not reachable.

Delete remote network policy and verify it has been deleted

Verify traffic returns to normal pattern when remote network policy is deleted.

Error handling: Add policy for non-existent remote network
NID RulesAdd and verify local NID rule

Verify traffic goes over the local NID with the highest priority


Verify traffic goes over the healthiest NID even if it has lower priority

Delete NID policy and verify it has been deleted


Verify traffic goes back to regular pattern after NID policy is deleted.

Error handling: Add policy for non-existent NID


Repeat the above tests for remote NID
NID Pair Rules

Add and verify NID Pair Rule

→ TODO: how do you verify that a NID Pair rule has been applied correctly. We need to show the preferred NID list in the show command. This also applies to Router Rules.


Verify traffic goes over the preferred Local NIDs

Delete NID pair rule a and verify it has been deleted

Verify traffic goes back to regular pattern after NID Pair policy is deleted.

Error handling: Add a policy that don't match any local NIDs. This should be a no-op
Router RulesSame set of tests as above but for routers
Subsequent AdditionFor each of the policy types, add a policy which doesn't match any thing currently configured. Verify that policy is added irregardless

Add an LNet construct (Net, NI, Route) which matches an existing policy. Verify that policy has been applied on construct

→ TODO: Show commands like net show, peer show, etc should be modified to show the result of the policy application.


Verify traffic adheres to policy

Delete LNet construct. Verify that policy remains.
Dynamic Policy Addition

Run traffic.

For each of the policy types add a policy which should alter traffic

Verify traffic patterns change when policy is added.

Policy application order

Add all types of policies. They all should match and be applied. Verify.

Run traffic.

Verify that policies are applied on traffic in the order of operations defined here.

Dynamic policy Deletion

Add all types of policies.

Run traffic

Verify that polices are applied on traffic in the order of operations defined.

Delete the policy one at a time.

Verify traffic pattern change with each policy deleted.

...

Breakdown

Functional Breakdown

In order to divide the work between multiple developers, we need to define a logical breakdown of the different functional components along API lines. By defining the APIs first, each developer can work on his carved piece independently. Below is a Function Block diagram highlighting the different API lines. The API blocks are in red.

User Space

  1. YAML
    1. YAML syntax as described earlier in the document
  2. CLI
    1. CLI syntax as described earlier in the document
  3. DLC API
    1. The set of API functions lnetctl (or any other utility) calls to perform policy operations
  4. Marshal API
    1. The API used to marshal and unmarshal UDSPs
  5. Parsing API
    1. The API used to parse a textual expression into 

Kernel Space

  1. Marshalled structure IOCTL API
    1. Used by both Kernel and User space
  2. Marshal API
    1. Should be the same for both Kernel and User space, except the implementation is duplicated
  3. Policy Management API
    1. Add, remove, apply policy
  4. Policy Storage Structure API
    1. These are the definitions of the UDSP structures when they are stored. The same definitions are used in both the user and kernel space. The marshal functions take these structures and form the marshalled IOCTL structures. The unmarshal functions take the marshalled IOCTL structures and forms the UDSP Storage structures

Gliffy Diagram
nameFunctionBlockDiagram
pagePin5

Schedule

PDF
nameUDSP-Timeline.pdf

Reference Links

...