Hide Forgot
Description of problem: Based on the documentation we can have these route specific time out settings enabled. https://docs.openshift.com/enterprise/3.2/architecture/core_concepts/routes.html#route-specific-timeouts After we edit the routes it seems that it doesn't pickup the annonations. Can we know if this is supported by the haproxy template router version 3.2.1.13 ? Version-Release number of selected component (if applicable): 3.2 How reproducible: On customer side Steps to Reproduce: a) oc edit < route name > add annonnations under the metadata feild. b) On the master oc rsh to the ha-router-primary pod and checked the pods backend entries to confirm if they annonations are taken into effect. We found that these settings had not taken into effect. c) we ran docker run --rm --interactive=true --tty --entrypoint=cat \ registry.access.redhat.com/openshift3/ose-haproxy-router:v3.2.1.13 haproxy-config.template and checked for the below entries which was not found. {{ end }} {{ with $value := index $cfg.Annotations "haproxy.router.openshift.io/timeout"}} {{if (matchPattern "[1-9][0-9]*(us|ms|s|m|h|d)?" $value) }}. Actual results: Expected results: Additional info:
This is a 3.3 feature that the docs were incorrectly merged over into 3.2. Unfortunately, we can not just add this feature to 3.2. It is part of a much larger change that we can not back-port because it breaks compatibility with the config file. I think the best that you can do for now is change the global timeout until 3.3 is available. I'm sorry for the confusion.
This has been reverted in the docs. https://github.com/openshift/openshift-docs/pull/3042
Hi, Original bz also set as "3.2.0" below: https://bugzilla.redhat.com/show_bug.cgi?id=1341312 I'm sorry, but we cannot accept multiple human error. Please fix this issue in 3.2.
The BZ above (#1341312) was a feature request opened with the Version set to 3.2. This is not in any way an indication of when the feature will be implemented. Typically the 'Version' is set, by the bug creator, to whatever is the most current version at the time they open the request. Engineering implemented and released this feature in 3.3. We are unable to backport this feature to 3.2 as it builds upon other, non backwards compatible, changes to the router template implemented in 3.3. We do greatly apologize that the docs for 3.2 were mistakenly updated. However, at this time the docs are correct. These features have been added to 3.3 and they are not (mistakenly) discussed in the 3.2 docs. If a customer needs this feature they will need to move to 3.3. I am sorry but because of both the size of the work and the fact that it would break 3.2 systems we will be unable to backport this work to 3.2.
> However, at this time the docs are correct. I'm sorry, I don't think so. Could you please check the parameters described around "Configuration Parameters" (Table 1. Router Configuration Parameters) in https://docs.openshift.com/enterprise/3.2/architecture/core_concepts/routes.html#available-router-plug-ins ROUTER_SYSLOG_ADDRESS, ROUTER_LOG_LEVEL and so on....
@Ben, @Eric Below information in same documentation is not true, is it? https://docs.openshift.com/enterprise/3.2/architecture/core_concepts/routes.html#available-router-plug-ins """ Configuration Parameters With all the items outlined in this section, you should be able to set environment variables on the deployment config for the router to alter its configuration. Table 1. Router Configuration Parameters ROUTER_SYSLOG_ADDRESS ROUTER_LOG_LEVEL ROUTER_BACKEND_CHECK_INTERVAL ROUTER_DEFAULT_CONNECT_TIMEOUT XROUTER_DEFAULT_CLIENT_TIMEOUT ROUTER_DEFAULT_SERVER_TIMEOUT ROUTER_DEFAULT_TUNNEL_TIMEOUT ROUTER_SLOWLORIS_TIMEOUT """"
@Kenjiro: You are right, another doc change was committed to the wrong branch. I've requested that be reverted too. I am now going through all doc commits to 3.2 to make sure that they were correctly applied to the right branch.