Add hostAlias (/etc/hosts entry) in OpenLibertyApplication CR

[faandg]

Feature Request

Is your feature request related to a generic (non-Open Liberty) problem?

If so, please open an issue with the upstream Operator, which gets pulled into this Operator.

No, it is specific to the OpenLiberty Operator.

Is your feature request related to a problem?

A clear and concise description of what the problem is. Example: "I have an issue when (...)"

When adding following lines in an OpenLibertyApplication CR:

  hostAliases:
  - hostnames:
    - foo.example.com
    ip: 10.150.20.60

This entry is not being added in /etc/hosts in the created containers.
hostAlias is not recognized in the OpenLibertyApplication custom resource. Verified this in the CRD.
According to this solution from Red Hat, it is included starting in Kubernetes 1.7 which started shipping in OpenShift 3.7.

Describe the solution you'd like

A clear and concise description of what you want to happen. Add any considered drawbacks.

Please add support for setting hostAlias in the OpenLibertyApplication CR.

[navidsh]

Hi @faandg, thanks for opening this issue. Can you please describe the user scenario you are trying to solve using hostAliases? The OpenLibertyApplication CRD only includes a subset of configurations for Deployments, Pod and etc. However, if this is a common use case, we could potentially update the CRD.

[faandg]

Hi @navidsh . The user scenario is simply adding host records in a container's /etc/hosts. There are many cases in which a user might decide to add host records: for testing purposes, a temporary workaround, split DNS. For our case it's because split DNS is used in our enterprise, now and then we require following a different network path.
Since it was added in base Kubernetes, I would imagine the use case being sufficiently common.

[navidsh]

Hi @faandg, we see two options to tackle this issue:

1. adding hostAliases to the OpenLibertyApplication CRD
2. proving a generic way for defining patches to be applied to resources created by the operator. Similar idea as kubectl patch.

Though option 1 provides a better user experience, we might end of with complicated and messy CRD. We have had other requests in the past to add other configuration fields that only power users would be interested in using.
With option 2, we can patch any resource that gets created as part of the reconcile loop. The downside is that it will not be as easy as defining a field.
We are still in the discussion about which option to pick and would appreciate any feedback you might have.

[faandg]

Hi @navidsh
After a short internal discussion with our team we unanimously agreed we prefer option 2.

It would prevent that you receive a feature request for many smaller features added to the Kubernetes specification, in which case you would probably need to make a selection of the most interesting/requested features to add to the CRD while having to reject others.

This approach would also be more future proof as we would have the flexibility to add other fields which are added through Kubernetes as well as soon as they become available through OpenShift.

Since you mention only power users would be interested in using this approach, I would expect power users to also have a certain level of technical knowledge required to implement this solution even if it is a bit more complex.

[navidsh]

Hi @faandg, Thanks for your input.

This approach would also be more future proof as we would have the flexibility to add other fields which are added through Kubernetes as well as soon as they become available through OpenShift.

You are right on this. Option 2 gives us lots of flexibility and extensibility for the future.
This issue would be on our backlog and as we have free up on other issues.

[dougbreaux]

I came searching for the same thing, which we need. Looks like even the patch approach never got implemented?

[dougbreaux]

Hmmm... although, colleague found that applying a patch to the Deployment for these elements does not seem to be overwritten by the olapp CRD.

spec:
  template:
    spec:
      hostAliases:
      - ip: "10.10.10.1"
        hostnames:
        -  myhost

In our case (OpenShift):

oc patch deployment myapp --patch-file /tmp/hosts.patch.yaml

[faandg]

@dougbreaux the deployment object is managed by the OpenLibertyApplication though (you can verify this in the OpenShift UI), so as soon as you deploy a new version of the olapp it will replace the existing deployment and your patch will be gone unfortunately.

[dougbreaux]

@faandg the thing is... that's what we expected, but is not what is happening 😕

[faandg]

@dougbreaux it depends on what part of the OLA spec you modify. Unless the behavior changed recently, for example changing the ApplicationImage should give you a new deployment and pods. But if you change some other part like the service ports, it's possible the deployment and pods still exist.

[dougbreaux]

@faandg I hear you, but it's the application image that we change regularly, and haven't lost the hostAliases entries 🤷