[Antctl] Support Traceflow

[lzhecheng]

Describe what you are trying to solve
Antctl doesn't support Traceflow and users can only use Traceflow through octant UI.

Describe the solution you have in mind
Antctl supports Traceflow. It can create Traceflow and retrieve results.

Describe how your solution impacts user flows

• Create Traceflow

antctl create traceflow/tf -S namespace/podSrc -D namespace/podDst // create a traceflow with namespace/pod
antctl create traceflow/tf -S namespace/podSrc -D DstIP // create a traceflow with namespace/pod and IP

e.g.

$ antctl traceflow -S busybox0 -D busybox1
name: default-busybox0-to-default-busybox1
phase: Succeeded
source: default/busybox0
destination: default/busybox1
noderesults:
- node: antrea-linux-testbed7-2
  role: ""
  timestamp: 1595391265
  observations:
  - component: SpoofGuard
    componentinfo: ""
    action: Forwarded
    pod: ""
    dstmac: ""
    networkpolicy: ""
    ttl: 0
    translatedsrcip: ""
    translateddstip: ""
    tunneldstip: ""
  - component: Forwarding
    componentinfo: Output
    action: Delivered
    pod: ""
    dstmac: ""
    networkpolicy: ""
    ttl: 0
    translatedsrcip: ""
    translateddstip: ""
    tunneldstip: ""

[antoninbas]

Is there an advantage to having 2 separate commands (one to create the CRD, one to get the result)? From a user perspective, I think it would be nicer to be able to run a single command, which would block until the CRD status becomes available. What do you think?

antctl traceflow -s namespace/podSrc -d namespace/podDst

[lzhecheng]

@antoninbas yes, I think it is good to wait for result when creating a new traceflow. Then what if user would like to check results of old traceflows? They may just want to see result of the last one instead of creating a new one.

This leads to another question about lifecycle of a traceflow. Should we keep traceflows forever? Or we may find a rule to do cleanup. What's your opinion?

[vicky-liu]

I think we once talked about the TF CRD lifecycle control in traceflow demo. One of the option is to have the TF CRD to trace the flow one-time and cleanup automatically by UI or by CLI after getting result. Otherwise, the stale TF CRD will increase a lot during a few years. However If it's the user to create TF CRD, then it's user to cleanup. cc @jianjuns @McCodeman for opinion.

[jianjuns]

On one hand, I think kbuectl apply + yaml is good enough and would not maintain multiple user interfaces; on the another hand I also agree antctl might still be more convenient for users. So, really have no strong opinion. Like to hear what others think.

[antoninbas]

I like the following:

• if a user wants to have full control, they can use kubectl and manipulate the CRDs directly
• if a user wants simplicity, they can use antctl with a single command; antctl will create the CRD, block until the status is available, display the result, then cleanup the CRD

[lzhecheng]

Thanks @jianjuns @antoninbas . Then antctl should take care of whole lifecycle of traceflows created by it.

[tnqn]

I think it's good to have antctl to create the traceflow object even it can also be done with kubectl.
Similarly, I always create pod, deploy, service by kubectl run, kubectl create deploy, kubectl expose, instead of searching for a yaml template, changing it, applying it, which takes quite a lot of time. antctl traceflow --args style command is much more convenient.

For the lifecycle management of Traceflow object: I think we can have a single field to indicate what user want to do with it:
DeadlineSeconds, which defaults to 1 minutes or a few. When it’s set, antrea-controller will delete the object after the duration.
With antctl traceflow, there could be an option to specify a different value, then it will be removed some time later by default, and can still be kept for comparison for a while, or longer time if specified.

I like the idea that antctl traceflow creates the CRD and waits for its result, we can also have an option "--wait=false" to change the behavior if user just want a non blocking operation. This could be similar to kubectl delete --wait.

[antoninbas]

I'm fine with additional flags to tweak the behavior, but I think the default should be the most common / simplest case for the user (wait for a reasonable amount of time and triggers the CRD deletion).

[lzhecheng]

Currently the very basic implementation of antctl traceflow is finished. It takes two required options: source and destination. Also, it creates, retrieves and deletes CRD as soon as the command returns.

Here are some remaining issues:

1. Support more options like those in Packet field.
2. Support "--wait" option. @tnqn In this case, I think the antctl just create the traceflow CRD, right? Then does a subcommand to retrieve result necessary? Or users can just use kubectl.

[lzhecheng]

@gran-vmv @mengdie-song Currently, command provides options for source and destination. How many other fields should be supported like header specs? I think this should be a quick and handy command to start a traceflow. If there are many fields to config, maybe applying a yaml file is better?

[jianjuns]

@gran-vmv @mengdie-song Currently, command provides options for source and destination. How many other fields should be supported like header specs? I think this should be a quick and handy command to start a traceflow. If there are many fields to config, maybe applying a yaml file is better?

I think you can also refer to antctl trace-packet command arguments. It uses OVS flow expression to define the packets. Let us first check if that can cover TF parameters or not.

[lzhecheng]

Thank you Jianjun! I added protocol and port options.