Hide Forgot
1. Proposed title of this feature request Custom routes 3. What is the nature and description of the request? In OSE/OCP 3, we can deploy custom routers, but it is complicated to influence specific routes via the template. It works fine for general configurations, but if you want to pass a specific value to 1 given route, the golang templating does not pass enough data. Also it would be nice for the people who want to create a custom router template that they know exactly which information is passed in via the context. 4. Why does the customer need this? (List the business requirements here) Some examples : * 1 given backend needs a high timeout, but we don't want to specify this for others * a given backend needs CORS headers to be added... only valid for that backend * a backend needs to pass an additional header to their clients. 5. How would the customer like to achieve this? (List the functional requirements here) In OCP 3 you already pass the environment (which is a clear improvement to 3.1), but we would like to pass this information from the route object. So a key/value map would be great so that the template can perform control flow on the data in the route, and also use values. Something like customData: - useSpecificTimeout: true - specificTimeout: "3ms" - useCORSHeaders: true - CORSHeader: - domain1 - domain2 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Create a route with the custom fields set, create a router template that uses them and see that only the route that contains the additional parameters gets modified 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? No idea 8. What information can you provide around timeframes and urgency? Not available 9. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? 3.4 10. List any affected packages or components. 11. Would the customer be able to assist in testing this functionality if implemented? Yes. We can deliver both testcases and test it (even in origin during development if you like)
*** Bug 1397008 has been marked as a duplicate of this bug. ***
In 3.3 we support the route annotation haproxy.router.openshift.io/timeout for setting the server and tunnel timeouts.
All route annotations are available to the template, and all router environment variables are also available. We have card https://trello.com/c/62X44q90 open to work on improving the template documentation, including how to use router annotations. The 3.3 documentation for configuring router timeouts is at: https://docs.openshift.com/container-platform/3.3/install_config/configuring_routing.html And there is more information about the annotations at: https://docs.openshift.com/container-platform/3.3/install_config/router/default_haproxy_router.html#deploy-router-protecting-against-ddos-attacks In 3.4 we have documented all of the router environment variables: https://github.com/openshift/openshift-docs/blob/master/architecture/core_concepts/routes.adoc#haproxy-template-router Many of those apply to 3.3, but we have not called those out explicitly.
*** Bug 1431130 has been marked as a duplicate of this bug. ***
From: 1431130 > 3. What is the nature and description of the request? Exposed applications running on OCP might have secure routes, which might become vulnerable in the event of a bug being disclosed for the set of ciphers, tls implementation, ... Some businesses might not be able to wait for a fix being provided and might require to workaround the issue themselves. The RFE is to have the ability to configure TLS settings per route. > 4. Why does the customer need this? (List the business requirements here) Customer operates in highly regulated environment and they need to be able to comply with the regulations and security standards. > 5. How would the customer like to achieve this? (List the functional requirements here) Quoting: "In general, we would like that users can customize as many TLS-related parameters as possible (TLS version, allowed ciphers...). If this is not possible, we (as cluster admins) would like to be able to define "security levels" and let the user choose one of them at their routes (having a "default" security level is acceptable)." > 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Example scenario: Application running on OCP has to comply with specific regulations, therefore would need to configure the TLS settings accordingly.
A couple of things: the OSE/OCP 3.3 and later docs include a discussion on customizing router templates (https://docs.openshift.com/container-platform/3.3/install_config/router/customized_haproxy_router.html#using-configmap-replace-template). I think that annotations coupled with a custom template would go a long way toward satisfying customer needs. Bear in mind that the template crates a haproxy.config file for haproxy 1.5. You can only customize features that are supported by haproxy 1.5 (http://cbonte.github.io/haproxy-dconv/1.5/configuration.html).
I'm sorry but we will not realistically have the ability to do work on this in the near future. With the major refactoring that happened with OpenShift 4 we will need to re-expose features from OpenShift 3 that were initially removed and adding additional features beyond the capability of 3.11 first is unlikely to have priority. We can consider addressing this sometime in the future, but please work with product management to try to better define the requirements for what you need control of.