4.0.0 is generating an unwanted sidecar copy of application instance

[mojsha]

Description

It looks like 4.0.0 is "auto-generating" an unwanted sidecar copy of the application instance.

It is easiest explained using screenshots:

Using 3.5.42, the application is running in container "demo":

Using 4.0.0, two instance of the application now are running, demo (as defined in a DC) and "demo-sample-t" (a concatenation of the DC name "demo" and namespace name "sample-t"):

As you can see, the "sample-t-demo" (sample-t is the name of the namespace) has been generated without any resource fragment.

Info

• f-m-p version :
  4.0.0
• Kubernetes / OpenShift setup and version :
  3.10
• If it's a bug, how to reproduce :
  Use a DC and upgrade to 4.0.0 and do the regular fabric8:resource fabric8:build fabric8:apply cycle. It should generate the unwanted sidecar.

@rohanKanojia

[rohanKanojia]

@mojsha : I can confirm that this is certainly a bug which needs to be fixed. This is a sideeffect of #1202 since fmp now considers container in fragment as a sidecar. We need to have some option in order to disable this autogeneration of the main container.

[rohanKanojia]

Hm, this is being done via ControllerViaPluginConfigurationEnricher which was earlier a part of DefaultControllerEnricher( see #401 ). You can get rid of this sidecar by excluding this enricher in your plugin configuration.

          <enricher>
            <includes>
              <include>fmp-portname</include>
            </includes>
            <excludes>
              <exclude>build</exclude>
              <exclude>fmp-controller</exclude>
              <exclude>fmp-controller-from-configuration</exclude>
            </excludes>
            <config>
              <f8-service>
                <type>NodePort</type>
              </f8-service>
            </config>
          </enricher>

[rohanKanojia]

@mojsha: Okay, so this enricher is creating two separate containers instead of one. So the idea of sidecar containers was to treat every container as sidecar whose name is not equal to default application container(which is generated by fmp). So if you take a resource fragment like this:

kind: "DeploymentConfig"
apiVersion: "v1"
spec:
  template: 
    spec:
      containers:
        - name: "spring-boot"
          image: "openjdk"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 3 

This won't generate sidecar since container name is specified and it is equal to default application container name. But if you change container name, then it would be treated as a sidecar. For example, this resource fragment would generate two containers in resulting deploymentconfig:

kind: "DeploymentConfig"
apiVersion: "v1"
spec:
  template: 
    spec:
      containers:
        - name: "spring-boot2122344"
          image: "openjdk"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 3 

So if container specified in resource fragment doesn't have a name or it's name is equal to default application's container name; it would not be treated as sidecar. You can manipulate fmp's default name for main container via this parameter: fabric8.generator.alias.

I would add it to documentation to avoid confusion in future.

[mojsha]

Ok, it seems that it works - but now I have another problem, in that the ImageChangeTriggers are not being generated.

[rohanKanojia]

@mojsha : yeah, we're not generating ImageChange triggers in case of resource fragments. I have created #1610 to resolve this. Could you please test it and provide feedback if it works for you?

[rohanKanojia]

I released 4.1.0 yesterday. Could you please try whether it solves your issue?

• In order to stop fmp generating sidecar, either don't provide name to the container or simply disable fmp-controller-via-configuration enricher
• In order to generate triggers with this setup use these flags :

-Dfabric8.openshift.enableAutomaticTrigger=false 
-Dfabric8.enricher.fmp-openshift-imageChangeTrigger.enrichAll=true

Here is a project(simlar to your setup) with which I tested this on 4.1.0: https://github.com/r0haaaan/fabric8-maven-plugin-sample-with-fragments

[mojsha]

@rohanKanojia Sorry for the delay. It looks like those two flags cannot be used in conjunction. I am getting the automatic field set to true.

[rohanKanojia]

@mojsha : Have you tried setting these two flags as properties in pom? that worked for me

[mojsha]

@rohanKanojia Yes it is working for some reason if it's in the pom. I have no idea why. But we need to find out why, as I cannot roll out this version of the application without making it work 'as-is'.

[rohanKanojia]

I think we should not treat fmp-openshift-imageChangeTrigger.enrichAll as a mojo parameter, it's for enricher configuration. It should be put into enricher config rather than a parameter. I would suggest you to add it to your enricher configuration like this:

	    <config>
	      <f8-prometheus>
		<prometheusPort>9779</prometheusPort>
	      </f8-prometheus>
	      <fmp-image>
		<pullPolicy>Always</pullPolicy>
	      </fmp-image>
	      <fmp-openshift-autotls>
		<pemToJKSInitContainerImage>openshift/pemtokeystore:v0.2.0</pemToJKSInitContainerImage>
              </fmp-openshift-autotls>
              <fmp-openshift-imageChangeTrigger>
                <enrichAll>true</enrichAll>
              </fmp-openshift-imageChangeTrigger>
            </config>

and use other flags like usual. I created an example much closer to your project configuration: https://github.com/r0haaaan/fabric8-maven-plugin-sample-with-fragments/

[mojsha]

Thanks, it's working now.