feat: support kubernetes equality-based ops for field selector metadata.name

[miltalex]

Partial fix for #13468

Motivation

Currently, our system only supports the '=' operator for the field selector metadata.name when interacting with Kubernetes resources. This limitation restricts the flexibility and functionality of our queries. The goal of this PR is to expand support to include the '==' and '!=' operators, aligning our capabilities with native Kubernetes functionality. This enhancement will provide users with more granular control over resource selection and filtering, improving overall system usability and compatibility with standard Kubernetes practices.

Modifications

1. ListOptions Expansion:

   • Extended the ListOptions struct to include a new NameOperator field.
   • This modification was necessary to support expanded operators for archived workflows retrieval.
   • For non-archived workflows, we continue to use metav1.ListOptions, which inherently supports additional operators.

2. BuildListOptions Enhancement:

   • Modified the BuildListOptions function to implement a more generic parsing of terms for metadata.name.
   • This change allows for extracting both the value and the desired operation from the input.

3. BuildArchivedWorkflowSelector Update:

   • Implemented a wrapper that is used in the BuildArchivedWorkflowSelector function.
   • This wrapper creates database conditions based on the new NameOperator field, enabling support for '==', '!=', and '=' operators.

4. Code Refactoring:

   • Adjusted related functions and methods to accommodate the new NameOperator field and expanded operator support.
   • Ensured backward compatibility with existing '=' operator usage.

Verification

1. Unit Testing:

   • Added comprehensive unit tests in list_options.go to cover the new functionality.
   • Expanded test coverage to ensure robustness of the implementation.

2. Local Testing:

   • Conducted local testing using a k3d cluster.
   • Created various workflows to simulate different scenarios.
   • Validated the functionality using the command: argo stop -n argo --field-selector metadata.name(=,==,!=)
   • Confirmed that all operations (=, ==, !=) work as expected for metadata.name field selection.

Example audit log from local testing:

   "kind":"Event",
   "apiVersion":"audit.k8s.io/v1",
   "level":"RequestResponse",
   "auditID":"e38e458a-62bc-4e77-ada0-2dc6fc7e5a06",
   "stage":"RequestReceived",
   "requestURI":"/apis/argoproj.io/v1alpha1/namespaces/argo/workflows?fieldSelector=metadata.name%21%3Dsleepy-mjqw9\u0026labelSelector=%21workflows.argoproj.io%2Fcontroller-instanceid",
   "verb":"list",
   "user":{
      "username":"system:admin",
      "groups":[
         "system:masters",
         "system:authenticated"
      ]
   },
   "sourceIPs":[
      "192.168.117.3"
   ],
   "userAgent":"argo/v0.0.0 (darwin/arm64) kubernetes/$Format/argo-workflows/latest+afa8ecc.dirty argo-api-client",
   "objectRef":{
      "resource":"workflows",
      "namespace":"argo",
      "apiGroup":"argoproj.io",
      "apiVersion":"v1alpha1"
   },
   "requestReceivedTimestamp":"2024-08-19T08:43:24.965180Z",
   "stageTimestamp":"2024-08-19T08:43:24.965180Z"

[Joibel]

Is there any reason this couldn't also be implemented for namespaces, it feels nearly identical?

[miltalex]

Is there any reason this couldn't also be implemented for namespaces, it feels nearly identical?

I noticed that for the namespace we need to adapt more codepaths. Mostly right now, we use the to validate access to the namespace. For the != we need to adapt it in a way that we query all the namespaces and if there is an error we return it (I have a stash as a WIP)

// verify if we have permission to list Workflows
allowed, err := auth.CanI(ctx, "list", workflow.WorkflowPlural, options.Namespace, "")

Apart from that there are the stores that need adapting one example which I didn't dive into cause it affects the clients as well.

wfList, err := k.wfClient.ArgoprojV1alpha1().Workflows(namespace).List(ctx, listOptions)

For the sqlite_store I need to adapt the BuildWorkflowSelector . As well the clusterManagedNamespaceAndInstanceID func for archived workflows. Those are the things I have noted until now, there might be cases that I have missed.

Since the namespace is touching a lot more components I thought I could split the MRs to make it easier for testing review etc

Please let me know @Joibel if I am mistaken or confused smth 🚀

[Joibel]

Thanks for your comprehensive answer, I hadn't realised namespace would be so far reaching. The separate PRs make sense.

[agilgur5]

We probably want to unify this with #13160 , which I need to re-review

[tooptoop4]

@miltalex i guess this needs some changes since #13160 has been merged. From what I can tell #13476 mentions != operator which other PR does not have

[miltalex]

@tooptoop4 yes I will spend some time this weekend. I will rebase and check what needs to be adjusted