Bug 1309528 - [RFE] Update HAproxy heat template to optionally configure RGW
Summary: [RFE] Update HAproxy heat template to optionally configure RGW
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 10.0 (Newton)
Hardware: All
OS: Linux
medium
unspecified
Target Milestone: ---
: 10.0 (Newton)
Assignee: Giulio Fidente
QA Contact: Yogev Rabl
URL:
Whiteboard:
Depends On:
Blocks: 1336839 1356451 1387433 1413723
TreeView+ depends on / blocked
 
Reported: 2016-02-18 03:15 UTC by Kyle Bader
Modified: 2017-01-16 19:43 UTC (History)
33 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
The director is now able to configure HAproxy load balancing and SSL termination for RADOS gateway (RGW) services collocated on OSP controller nodes.
Clone Of:
Environment:
Last Closed: 2016-12-16 16:51:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kyle Bader 2016-02-18 03:15:24 UTC
Description of problem:

Currently, Jetstream is using custom scripting to provide load balancing for RGW instances deployed on OSP controllers. In their configuration, they are piggybacking on the HAproxy used to balance and provide HA for OSP API endpoints. Ideally the Heat template used to configure HAproxy for OSP services should include an option to load balance RGW instances, if they exist.

Expected results:

When RGW is deployed on OSP controller nodes, the HAproxy Heat template should detect their existence and add appropriate fontend and backend entries for those RGW instances. Additionally, HAproxy should use L7 load balancing for RGW, and be configured to terminate TLS with the appropriate strong ciphers. RGW is now civetweb based, it does not have a means of providing transport encryption to the client.

Comment 2 Kyle Bader 2016-02-18 03:20:26 UTC
Mozilla recommendations for TSL termination using HAproxy:

https://wiki.mozilla.org/Security/Server_Side_TLS

Comment 3 arkady kanevsky 2016-02-18 05:03:14 UTC
adding related work for it upstream (for RGW support, not HA)

Comment 4 Alan Bishop 2016-04-13 19:25:18 UTC
No longer blocks delljs5.0 because we have a workaround.

Comment 6 seb 2016-11-04 09:43:01 UTC
As far as I know, due to recent patches in OSP10 for rgw support this requirement is fixed. So if we use rgw as a replacement for swift, rgw will use swift haproxy configuration.

Keith, do you mind sharing an example of the haproxy section for rgw in this case?

Thanks!

Comment 7 Giulio Fidente 2016-11-09 17:09:08 UTC
From OSPd10 the haproxy.cfg file will include a listener for the RGW backends. For example in an IPv6 environment it will include something like the following:

  listen ceph_rgw
    bind 2001:db8:fd00:1000::14:8080 transparent
    bind fd00:fd00:fd00:3000::10:8080 transparent
    server overcloud-controller-0.storage.localdomain fd00:fd00:fd00:3000::19:8080 check fall 5 inter 2000 rise 2

where

2001:db8:fd00:1000::14 is the public endpoint for swift (rgw) service
fd00:fd00:fd00:3000::10 is the internal ednpoint on the storage network
fd00:fd00:fd00:3000::19 is (one of) the target rgw nodes

This section is automatically (and only) included when RGW is deployed, replacing a similar listener usually created for Swift.

If sufficient, I think we can close this as CURRENTRELEASE?

Comment 8 arkady kanevsky 2016-11-09 17:15:39 UTC
will it work for IPv4 and IPv6?
will it work when swift is there and swift is not there? It definitely must work without swift.

Comment 9 Giulio Fidente 2016-11-09 17:19:33 UTC
Yes, this should work with IPv4 and IPv6 deployments.

Swift and RGW cannot be deployed together in the same overcloud by OSPd; when RGW is chosen, it will be deployed as a drop-in replacement for Swift. Clients will continue to use the standard Swift client to operate against an RGW server.

The relevant haproxy configuration will be applied depending on which service is deployed.

Comment 10 arkady kanevsky 2016-11-09 17:26:18 UTC
right. either swift or ceph object store. Hope there is a check for it.


Note You need to log in before you can comment on or make changes to this bug.