feat: add Deployment and Service columns to kubectl get spinapps -o wide

[Achanandhi-M]

Description

This PR addresses the #168 to add more information to kubectl get spinapps -o wide. Specifically, it adds DEPLOYMENT and SERVICE columns to the output.

These columns are configured with priority: 1, which means they only appear when using the -o wide flag, keeping the default output clean.

Changes

• Updated SpinApp struct in api/v1alpha1/spinapp_types.go with kubebuilder:printcolumn markers.
• Regenerated CRD manifests (make manifests).

Verification Results

I have verified these changes locally by applying the updated CRDs to a cluster.

Output

[vdice]

Thanks @Achanandhi-M, this looks great. Posting as a general comment for now to allow other core Spin Operator contributors to chime in.

I had a thought around perhaps updating how we consume the values for the deployment and service names in the future in case the naming convention were to change, but today since the app name is used for both, this works well (and my idea might not even be feasible 😄).

Another quick thought: would it be worth adding test coverage for this new output? I'm wondering if the default e2e test might be an eligible place to put new validations? It could also be a follow-up we can create, since it might involve a bit more learning about the test harness, etc.

[Achanandhi-M]

Hi @vdice, thank you for the feedback and the brainstorm!

I have updated the PR to follow your suggestions:

1. Avoided Naming Assumptions: I added deploymentName and serviceName fields to the
   SpinAppStatus struct. The controller now populates these fields when it reconciles the resources.

2. Updated Columns: The printer columns now use these explicit status fields (.status.deploymentName and .status.serviceName) instead of just repeating the app name from metadata.

3. E2E Testing: I've added a new assessment step to the TestDefaultSetup in e2e/default_test.go to verify that the operator correctly populates these fields in the status.

I've verified the logic with unit tests and regenerated the manifests. Let me know what you think!

[vdice]

@Achanandhi-M thanks so much for diving in further to make these recent updates! This is looking really good. I had a few more thoughts when you get a chance.

[vdice]

I think we should move this line further below, when we know the Deployment actually exists, probably here.

Then, we can update this line to be: app.Status.DeploymentName = deployment.Name.

[vdice]

Although this function calls r.findDeploymentForApp to get the Deployment resource for an app (which we can then extract the name from), we don't yet have an r.findServiceForApp to get the name of the service directly.

Would you like to take a crack at adding such a function and calling it here, so that we can set eg app.Status.ServiceName = service.Name? Alternatively, I would also be happy to relegate to a follow-up, eg:

# TODO: find Service resource for this app and set to 'service.Name'
app.Status.ServiceName = app.Name

[vdice]

For this check and the service check below, I'm thinking it would be better to check the actual resources directly. Both the Deployment and the Service will have a Label with the corresponding app name, eg core.spinkube.dev/app-name=simple-spinapp, so we should be able to utilize the K8s client to fetch these and then compare to the resource names, instead of the hard-coded testSpinAppName.

(Again, yes, they all use the same name today, as we've seen in the code -- but they could differ at some point, so it would be preferable to inspect the resources directly.)