Hide Forgot
Description of problem: We would like to be able to change the mysql listen haproxy configuration via heat templates. listen mysql bind 172.16.20.10:3306 transparent option tcpka option httpchk stick on dst stick-table type ip size 1000 timeout client 90m timeout server 90m server overcloud-controller-0 172.16.20.15:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2 server overcloud-controller-1 172.16.20.14:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2 server overcloud-controller-2 172.16.20.13:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2 Version-Release number of selected component (if applicable): OSP-d 7+ How reproducible: Try deploy with maxconn 6144 for mysql service. Steps to Reproduce: 1. 2. 3. Actual results: Default maxconn used. Expected results: Able to configure the maxconn value for mysql service. Additional info: We could probably use same template as for haproxy defaults: parameter_defaults: controllerExtraConfig: tripleo::loadbalancer::mysql_listen_options: - 'option tcpka' - 'option httpchk' - 'maxconn 6144' - 'timeout client 90m' - 'timeout server 90m' - 'stick-table type ip size 1000' - 'stick on dst'
The problem here is that some options can be configured in more than one way. For example, to tune the 'maxconn' parameter, you can also use the following fragment: cat ~/heat/templates/maxconn-haproxy.yaml parameter_defaults: controllerExtraConfig: tripleo::loadbalancer::haproxy_default_maxconn: 8192 But my point here is that using additional Heat templates is cumbersome and error prone. The maximum number of connections should be a first-level Heat parameter, not some random Hieradata in a YAML file wrapped in an ExtraConfig object. And for the record, even you implement this in OSP10, it should be change easy to backport to OSP7 as the Puppet code involved here as changed very little between OSP7 and OSP10 (I'd even say it hasn't changed at all).
So, I'm trying to get a grip on the scope of what's being asked for. We have: 1. set maxconn for haproxy / mysql via first class heat variable - OK 2. other "listen" parameters, which are currently (this is from the puppet template): 'option' => [ 'tcpka', 'httpchk' ], 'timeout client' => '90m', 'timeout server' => '90m', 'stick-table' => 'type ip size 1000', 'stick' => 'on dst', At most I can see wanting to change "timeout client" or "timeout server", but 90m is based on the 60m lifespan of a DB connection on the application-side connection pools, these are reasonable defaults that I don't see much advantage to changing. The "stick" settings refer to how we apply an incoming DB connection to a backend, which is that we "stick" on just one of them. Changing this behavior is not supported AFAIK, as all of our testing is against the "everyone goes to one Galera node" behavior. 3. there are then the "member" options, that is for the three servers, which in current code are "'backup', 'port 9200', 'on-marked-down shutdown-sessions', 'check', 'inter 1s'". I see in the example above, there is illustrated "backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2". This part is configurable on the puppet side as tripleo::haproxy::mysql_member_options and you can supply the whole list of keywords that you want. So. While the title of this bug says "allow changing the mysql_listen_options", I'm getting the impression we are looking right now just to have "maxconn" be a configurable value both on the Puppet side and later in haproxy.yaml on the Heat side. I'm going to start looking at just maxconn, unless folks want to chime in here with more specifics of what they'd like to see.
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.
maxconn has since been made configurable.