Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-17947

todo-backend Readme OpenShift instructions results in a non-functional QS app

XMLWordPrintable

    • ---
    • ---

      Description of problem:

      todo-backend QS recently got a Helm chart update (todo-backend-chart folder was removed, charts/helm.yaml file was added), which results in a deployable, yet non-functional QS app on OpenShift.

      Version-Release number of selected component (if applicable):

      Starting from 28.0.0.Final

      How reproducible:

      100%

      Steps to Reproduce:

      $ git@github.com:wildfly/quickstart.git
$ cd quickstart/todo-backend
$ helm install todo-backend -f charts/helm.yaml wildfly/wildfly
$ curl -k https://$(oc get route todo-backend --template='{{ .spec.host }}')

      Actual results:

      $ curl -k https://$(oc get route todo-backend --template='{{ .spec.host }}')
$ port out of range:-1

      Expected results:

      $ curl -k https://$(oc get route todo-backend --template='{{ .spec.host }}')
$ []

      Additional info:

      A misconfiguration possibly?

            [WFLY-17947] todo-backend Readme OpenShift instructions results in a non-functional QS app

            Brian Stansberry added a comment -

            Bulk closing issues resolved in the 29.0.0.Final release.

            Brian Stansberry added a comment - Bulk closing issues resolved in the 29.0.0.Final release.

            Farah Juma added a comment -

            ehugonne1@redhat.com Just FYI, we still need a PR against the wildfly quickstarts 28.x branch for this one (this issue has the WildFly 28.0.1.Final fix version on it).

            Farah Juma added a comment - ehugonne1@redhat.com Just FYI, we still need a PR against the wildfly quickstarts 28.x branch for this one (this issue has the WildFly 28.0.1.Final fix version on it).

            Emmanuel Hugonnet added a comment -

            This is due to the fact that for default port (aka 80 but I suspect that 443 could have the same issue) we are loosing the information in the request URI.

            Emmanuel Hugonnet added a comment - This is due to the fact that for default port (aka 80 but I suspect that 443 could have the same issue) we are loosing the information in the request URI.

            Emmanuel Hugonnet added a comment -

            In the cli script if I do :

            1. OTEL
              /subsystem=microprofile-telemetry:remove()
              /subsystem=opentelemetry:remove()

            then it works

            Emmanuel Hugonnet added a comment - In the cli script if I do : OTEL /subsystem=microprofile-telemetry:remove() /subsystem=opentelemetry:remove() then it works

            Emmanuel Hugonnet added a comment - - edited

            This is due to opentelemetry integration. jaslee@redhat.com could you please take a look on this ? My understanding is that the port is not defined (since it is 80) in the URI thus the InetSocketAddress is failing

            Emmanuel Hugonnet added a comment - - edited This is due to opentelemetry integration. jaslee@redhat.com could you please take a look on this ? My understanding is that the port is not defined (since it is 80) in the URI thus the InetSocketAddress is failing

              ehugonne1@redhat.com Emmanuel Hugonnet
              szhantem@redhat.com Sultan Zhantemirov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: