OTG-HW binding for Ondatra-featureprofile to run OTG test about ondatra HOT 10 CLOSED

@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

from ondatra.

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

from ondatra.

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.

from ondatra.

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?

from ondatra.

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

from ondatra.

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.

from ondatra.

@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?

from ondatra.

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 (

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"
}

from ondatra.

@greg-dennis Thanks!

from ondatra.

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

from ondatra.