Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-8040

Update the example to expose the service in TLS Client Certificate Validation to be consistent with the operator deployment

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • None
    • 2.11.1 GA
    • Documentation
    • API CCS Sprint 44 (3Scale) 2

      When upgrading to 2.11 the httpsPort field in the APIManager CRD should be used. Refer to THREESCALE-8039. When updating the APIManager with the httpsPort: 8334 the Service is updated with a named port/target port httpsproxy automatically.

      However there is an inconvenience for customers: the old routes, since they were created manually because the self-managed option is needed to configure TLS, have a target port named "https" (or any other name of their choice) as suggested in our documentation in the patch command of the service:

      $ oc patch service apicast-staging -p '{"spec":{"ports":[{"name":"https","port":8443,"protocol":"TCP"}]}}'
      

      So when upgrading, new routes will have the target port named httpsproxy and work correctly but the target port for the old routes has to be updated manually from the named  port "https" to "httpsproxy".

      The request is to update the example in the current documentation and use the same convention httpsproxy so that customers won't have to update the named port manually.

      $ oc patch service apicast-staging -p '{"spec":{"ports":[{"name":"httpsproxy","port":8443,"protocol":"TCP"}]}}'
      

              Unassigned Unassigned
              rhn-support-avilatus Anna Vila Tusell
              Darren Fennessy Darren Fennessy
              Matej Dujava Matej Dujava
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: