OpenLibertyApplication in Openshift cloud cluster

Question

Problem

Deploying OpenLibertyApplication rewrites the /config/server.xml specified in the container image

What did you do?

Deployed OpenLibertyApplication with initial configuration in src/main/liberty/config/server.xml:

    <httpEndpoint id="defaultHttpEndpointss"
                  host="*"
                  httpPort="8080"
                  httpsPort="9443" />

Changed port above to

    <httpEndpoint id="defaultHttpEndpointssssssssss"
                  host="*"
                  httpPort="8080"
                  httpsPort="8083" />

Docker build copies this server.xml to /config/server.xml (Docker pull-ing the image to my local shows the correct updated /config/server.xml)
Deployed the new image using the OpenLibertyApplication supported by Open Liberty Operator from OperatorHub version 0.7.0 using oc apply -f openlibertyapplication.yaml:

apiVersion: openliberty.io/v1beta1
kind: OpenLibertyApplication
metadata:
  name: vehicle
  labels:
    app: vehicle
    name: vehicle
    service: vehicle
    version: v2
spec:
  applicationImage: quay.io/xxxx/xxxxx:latest
  createAppDefinition: false
  version: v2
  service:
    port: 8080
    portName: http
  expose: true

server.xml:

<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">

    <featureManager>
        <feature>servlet-4.0</feature>
        <feature>springBoot-2.0</feature>
    </featureManager>

    <httpEndpoint id="defaultHttpEndpointssssssssss"
                  host="*"
                  httpPort="8080"
                  httpsPort="8083" />

    <springBootApplication id="vehicle"
                           location="thin-vehicle-0.0.1-SNAPSHOT.jar"
                           name="vehicle" />

</server>

What did you expect to see?

/config/server.xml in the Openshift pod showing the correct updated port for httpEndpoint http: 8080, https: 8083

What did you see instead? Under which circumstances?

Instead, I'm seeing the old port values on the Pod /config/server.xml, http: 8080, https: 9443. Id remains the old value too: id="defaultHttpEndpointss"

Environment

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:23:52Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0+2817867", GitCommit:"2817867655bb7b68215b4e77873a8facf82bee06", GitTreeState:"clean", BuildDate:"2021-06-02T22:14:22Z", GoVersion:"go1.15.7", Compiler:"gc", Platform:"linux/amd64"}

OpenShift version information (if applicable):

Client Version: 4.7.0-202104250659.p0-95881af
Server Version: 4.7.16
Kubernetes Version: v1.20.0+2817867

Thanks in advance!

I'd double check your docker image building process as operator is not modifying provided `server.xml` based on my tests and default values would be `9080,9443` not `8080`. Open terminal in your deployed pod and check `server.xml` file there. — Gas, Jul 05 '21 at 08:58
Hi gas, thanks for your input. However, the first round of configuration I made had 8080, 9443 that's why it was using 8080 for HTTP instead of 9080. Also, I checked my deployed pod and the server.xml is still using the old port values. That's why I'm confused. Thanks. — sam, Jul 05 '21 at 09:10
@Gas I've tested with a few new microservices, it's always the first round of configuration that works, subsequent changes on the `httpEndpoint` configuration of `server.xml` won't reflect anymore. — sam, Jul 05 '21 at 09:12
This is not possible. You are probably using your older image version and thats the reason. Try to create new tag and use that tag in your deployment instead of `latest`. Might be that older, `latest` version is cached on the OCP cluster. — Gas, Jul 05 '21 at 09:31
Make sure you add `pullPolicy: Always` in your `spec` section. — Gas, Jul 05 '21 at 09:35
Hi @Gas, thanks for your prompt response, I've changed the tag and it works now. Thank you so much! It's probably the pullPolicy that screwed me over. Thanks :D — sam, Jul 05 '21 at 09:46

score 2 · Accepted Answer · answered Jul 05 '21 at 10:39

The problem in this case was cached image with the latest tag. If the application is created without specifying policy, it is set to pullPolicy: IfNotPresent to optimize creating container. Since the OP first created image with incorrect settings, and then overwrite image with the same tag, OCP used cached version.

To ensure that you are using correct image either:

change the tag name
set pullPolicy: Always in your application definition