ServiceAccount binding not being generated in deployment

[nightswimmings]

Describe the bug

Even though documentation states https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin#serviceaccount-generation
that one can bind the deployment to a serviceaccount by using

<configuration>
    <resources>
      <serviceAccount>my-existing-serviceaccount</serviceAccount>
    </resources>
</configuration>

I just observed that there's no trace of such setting on the generated deployment.yml resource

The create approach, first described in the documentation, works fine but I have a preexisting serviceaccount so i dont want to generate it. I also tried using skpiCreate on the enricher with everything defined with ServiceAccounts, but still it fails

Eclipse JKube version

1.9.1

Component

Kubernetes Maven Plugin

Apache Maven version

3.6.1

Gradle version

No response

Steps to reproduce

Use a 1.9.1 JKube configuration with

 <configuration>
      <resources>
          <serviceAccount>existing-serviceaccount</serviceAccount>

the generated kubernates.yml/deployment.yml dont include serviceAccount on the spec

Expected behavior

deployment should contain the template.spec.serviceAccountName property with the value as per the definition in the POM plugin configuration section

Runtime

Kubernetes (vanilla)

Kubernetes API Server version

other (please specify in additional context)

Environment

macOS, other (please specify in additional context)

Eclipse JKube Logs

No response

Sample Reproducer Project

No response

Additional context

One can see the omission by inspecting generated descriptors, no need to test the integration with kubernetes

[rohanKanojia]

Are you generating Deployment using JKube zero configuration mode or using your own fragment? For me, it seems to work for zero configuration mode but not when I'm using a Deployment fragment.

I also tried using skpiCreate on the enricher with everything defined with ServiceAccounts, but still it fails

Are you sure about this? We have an integration test to verify this ServiceAccountIT

[nightswimmings]

I am using my own deployment.yaml fragment. Currenlty to work it out I am using
a manual serviceAccountName property in my deployment.yml, with the enricher config as <skipCreate>true</skipCreate>, otherwise, even if the serviceaccount is not generated from pom declaration it still generates the serviceAccount descriptor

[rohanKanojia]

I've observed ServiceAccountEnricher seems to only consider <resources> > <serviceAccounts> option not <serviceAccount> . <serviceAccount> only seems to be consumed while generating opinionated Deployments. This configuration seems to be working when using a deployment fragment:

          <configuration>
            <resources>
              <serviceAccounts>
                <serviceAccount>
                  <name>my-existing-serviceaccount</name>
                  <deploymentRef>${project.artifactId}</deploymentRef>
                </serviceAccount>
              </serviceAccounts>
            </resources>
        ...

We need to make changes to ServiceAccountEnricher to consider <serviceAccount> option as well.

[manusa]

We might want to deal with the ResourceConfig pojo and maybe remove the getServiceAccount getter, or evaluate how both configurations should be merged.

[rohanKanojia]

Since v1.11.0, <serviceAccount> configuration option has stopped working. ServiceAccount reference was removed from PodTemplateHandler in #1969

Before v1.11.0, it used to work for zero configuration mode but not when user provides a deployment fragment.

[rohanKanojia]

We moved serviceAccount configuration related logic to ServiceAccountEnricher in #2190 . This issue should be fixed by that.

I have checked with serviceAccount configuration option with and without depoyment.yaml fragment, it seems to add serviceAccountName in generated Deployment manifest. ServiceAccountNameViaGroovyDSLIT should also verify this scenario.

[rohanKanojia]

I've created #2196 for merging two configuration options. I think this issue can be closed.

[rohanKanojia]

@nightswimmings : Sorry for the extremely late reply. We have released v1.13.0 which should contain fix for your ServiceAccount issue. Would appreciate if you could try it out whenever you get time..