OTG-HW binding for Ondatra-featureprofile to run OTG test

[alakendu]

Requirements

• gRPC, gNMI, Ixia-c and OTG-HW are deploy using docker compose and connected to HW chassis.
• gRPC and gNMI server endpoint are required to run OTG test in featureprofile
• User have to configure Chassis IP, Card, Port and Speed information in binding or testbed file.

Proposal

• We will utilize StaticBinding present in featureprofile to run IxNetwork HW ATE test.
• OTG test must be execute:

cd ./topologies/otg_tests/topology_test
go test -v . -testbed ../../atedut_2.testbed -binding ../../atedut_2.binding

• Expose another property called otg within device binding
• This is a sample ate binding section within ../../atedut_2.binding

ates {
  id: "ate"
  name: "10.39.33.143"  # Change this to the Ixia chassis name.

  # This option specific to OTG over Ixia-HW. 
  otg {
    target: "127.0.0.1:40051" # Change this to the Ixia-c-grpc server endpoint.
  }

  gnmi {
    target: "127.0.0.1:50051"  # Change this to the Ixia-c-gnmi server endpoint.
  }

  # Before this binding can be used with a topology, add ports mapping
  # from its topology ID to the actual port name on the device.
  ports {
    id: "port1"
    name: "2/5"  # Change this to the actual port name.
  }
  ports {
    id: "port2"
    name: "2/6"  # Change this to the actual port name.
  }
}

[SubhajitPalKeysight]

@jasdeep-hundal @greg-dennis Would you please offer your feedback and comment on this.

[greg-dennis]

Please give us a week to review as we have current Sprint tasks that need to be complete. Added @liulk for any comments he may have on the static binding changes.

[liulk]

Does ixia-c really need to run inside a container as opposed to a standalone binary? Docker seems rather heavyweight. If we can run ixia-c gnmi/snappi server, controller, and hw controller from a shell script as an unprivileged user, then the static binding can just start them on demand and use reasonable defaults for the otg/gnmi ports.

By the way, the name of the dial options fields refer to the protocol or service that we expect to find there rather than the API. I know that otg is the API, but is it also the name of the gRPC service?

[alakendu]

As per communication with @greg-dennis
1. We prefer it to be deployed as a docker container. We envision it replacing the dockerized IxNetwork that we have recently enabled.
2. We have a preference for docker compose, because we know we know Google Linux installations provide that already.

This is a new docker which has a relatively lesser memory footprint compared to regular IxNetwork.

I have proposed otg name as we are planning to reuse DialOTG for this static binding. Your concern is also valid. There are few names I can think of otghw or ixiachw

[liulk]

Yes, Greg and I also talked about this yesterday, and he brought up the possibility of running the Ixia-C docker on a different host than the test as a long running service. Also, as far as the static binding is concerned, it makes sense that the otg represents the hw chassis and therefore are synonymous.

I think given that, otg seems like a reasonable name for the dial option.

[jasdeep-hundal]

@alakendu:

• The diagram you posted shows the test running on the same Linux machine as the ixia-c containers. Can you confirm that it's not necessary for a test to run on the same machine?
• Is it possible for multiple tests to use the same ixia-c instance simultaneously? (Is there a similar concept to 'sessions' on IxNetwork?)
• Can you clarify 'name' in the comment "# Change this to the Ixia chassis name.". Does 'name' refer to the host/domain name of the chassis (and therefore could actually be IP as well), or does it mean something else?
• How is ixia-c itself configured with the physical chassis IP/hostname? Is that done per-test session, or is it configured at the container level? Related question: can one ixia-c deployment configure multiple physical chassis?
• The DialIxNetwork method (

  ondatra/binding/binding.go

  Line 163 in 5011bd2

  DialIxNetwork(context.Context) (*IxNetwork, error)

  ) of the ATE Interface returns an IxNetwork type that includes an optional chassis IP because an IxNetwork instance may not be able to resolve the chassis hardware ports using the same host/domain name as listed in the ATE configuration. Do we need to provide a similar mechanism through DialOTG?

[alakendu]

Please find inline comments:

• The diagram you posted shows the test running on the same Linux machine as the ixia-c containers. Can you confirm that it's not necessary for a test to run on the same machine?

Yes, user can run test from any system

• Is it possible for multiple tests to use the same ixia-c instance simultaneously? (Is there a similar concept to 'sessions' on IxNetwork?)

No, It is not possible.

• Can you clarify 'name' in the comment "# Change this to the Ixia chassis name.". Does 'name' refer to the host/domain name of the chassis (and therefore could actually be IP as well), or does it mean something else?

Yes, name could be IP-address/ host name

• How is ixia-c itself configured with the physical chassis IP/hostname? Is that done per-test session, or is it configured at the container level? Related question: can one ixia-c deployment configure multiple physical chassis?

ixia-c work as a proxy. Ixia-c-HW docker responsible to configure physical chassis.
Ixia-c-HW can run against multiple physical chassis. But, I feel staticBinding have limitation to run multiple chassis if we consider similar IxNetwork concept.

• The DialIxNetwork method (

  ondatra/binding/binding.go

  Line 163 in 5011bd2

  DialIxNetwork(context.Context) (*IxNetwork, error)

  
  ) of the ATE Interface returns an IxNetwork type that includes an optional chassis IP because an IxNetwork instance may not be able to resolve the chassis hardware ports using the same host/domain name as listed in the ATE configuration. Do we need to provide a similar mechanism through DialOTG?

] I feel you are referring to (

ondatra/internal/ate/topology.go

Line 57 in 5011bd2

Location: ixconfig.String(fmt.Sprintf("%s;%s", ix.chassisHost, strings.ReplaceAll(port, "/", ";"))),

)

Yes, for ixia-c-hw also require similar mapping. At the same time our plan is to run OTG test against ixia-c-hw. But, DialOTG interface will return gosnappi.GosnappiApi. So, I am thinking to overwrite port name at the time of reservation.

        if bd.Otg != nil {
                 p.Name = fmt.Sprintf("%s;%s", bd.Name, strings.ReplaceAll(bport.Name, "/", ";"))
        } else {
                 p.Name = bport.Name
        }

As an alternative we also think to provide port location within port name

ports {
    id: "port1"
    name: "10.39.33.143;1;1"
}

[greg-dennis]

@alakendu I think it makes sense for the port name to be rewritten to the "fully-qualified location" of the port that includes the chassis hostname/IP. Sound good?

I have also filed a GoSnappi feature request that would eliminate the need for you to encode the full location in the port name: open-traffic-generator/snappi#187

[alakendu]

@greg-dennis Thanks!

[greg-dennis]

Great! Closing issue as the design seems substantially resolved and reviewed.