We set a value of -1 for the open_files_limit in galera.conf

[Marios Andreou]

The tripleo-heat-templates specify a value of -1 for the open_files_limit for galera.conf, like [1]. We eventually pass in a sensible value like at [2] however this gets passed as argument to the galera startup rather than written to the configuration file. Instead the config files get '-1', which based on [3] is not a valid value (0...). It may be that '-1' is/will be interpreted as '0' but it is better to be explicit and set it to that.

For example you can check on a controller node:
[root@overcloud-controller-0 etc]# grep open_files_limit /etc/my.cnf.d/*
/etc/my.cnf.d/galera.cnf:open_files_limit = -1

I don't think this is a serious bug, but was reported to me and is very cheap to fix, at least making it 0 by default. Fixup incoming

thanks, marios

[1] https://github.com/openstack/tripleo-heat-templates/blob/99bd9970d6bedee8228a6c8ff3d6f45aa1380e22/puppet/manifests/overcloud_controller_pacemaker.pp#L146
[2] https://github.com/openstack/tripleo-heat-templates/blob/99bd9970d6bedee8228a6c8ff3d6f45aa1380e22/puppet/manifests/overcloud_controller_pacemaker.pp#L376
[3] https://mariadb.com/kb/en/mariadb/server-system-variables/#open_files_limit

[Marios Andreou (marios-b)]

many thanks to martin andre for bringing the issue to my attention

[Marios Andreou (marios-b)]

fixup at https://review.openstack.org/#/c/255848/

[Marian Krcmarik (mkrcmari)]

I've seen mysql_safe log to complain about open_file_limits to be set to -1. So I was poking around and the situation is a little bit confusing.

Afaik open file limit is set for mysqld daemon as value calculated in following way:
max(max(10+max_connections+table_cache_size*2, max_connections*5), open_files_limit) where max_connections, table_cache_size and open_files_limit are configurable items in galera.cnf.
In the case of openstack deployed by tripleo the max value is "max_connections*5" (we set max_connections in galera.cnf to 4096 + 1 extra connection) which is 20485 and this number is set as open file limit of mysqld. Even though open_files_limit is incorrectly set to -1, It's overridden by setting --open_file_limits=16384 option when galera resource agent starts mysqld_safe in mysql_common.sh [1](but 16384 is still lower than 20485). In this case setting open_file_limits in galera.cnf to 0 should work as expected.

The question is how was it possible I saw mysqld_safe complaining about open_file_limits being set to -1. The reason is that when a failover in HA based Openstack happens and resource agent tries to handle recover of galera node, It starts mysqld_safe to find last commit in detect_last_commit() without the option --open_files_limit so the value of open_files_limit from galera.cnf is used [2], currently -1, The thing is that mysqld_safe script does not calculate open files limit as mysqld (described above) but simply just takes open_file_limits and do "ulimit -n $open_files" [3]. If we use suggested patch and set open_files_limit to 0, the ulimit of opened file would be set to 0 directly and mysqld_safe command started in galera resource agent would file due to "Too many files opened".

The quick solution would be to set open_files_limit in galera.cnf to something high enough or fix the galera resource agent to use --open_files_limit option when starting mysqld_safe to find last commit after failover. But I do not like the fact that open_files_limit option can be set at two different places, either in galera.cnf or as galera resource attribute while resource attribute overrides open_files_limit set in galera.cnf and the other options set in galera.cnf (max_conenctions, table_cache_size) have influence at final value set as the limit. The best would be to set it at one place - galera.cnf and remove the resource attribute "additional_parameters=--open-files-limit=16384" from galera resource. I would suggest values for galera.cnf:

max_connections = 4096
open_files_limit = 20485

If and admin want to increase the value of open file limit, They can increase the number of connections or open_files_limit option in galera.cnf and does not need to keep in mind that galera resource could override open_files_limit value when starting mysefld_safe.

[1] https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql-common.sh#L227
[2] https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/galera#L658
[3] https://github.com/MariaDB/server/blob/10.1/scripts/mysqld_safe.sh#L748

[Tim Rozet (trozet)]

I think this bug goes a little farther than just the setting in galera.cnf. The default ulimit setting is 1024, so no matter what mariadb calculates the value to be, it will always be set to 1024. At least that is what I see on noHA deployments. We see noHA deployments eventually stop working because we see:
 DBAPIError exception wrapped from (pymysql.err.InternalError) (23, u'Out of resources when opening file \'/tmp/#sql_b6c0_1.MAI\' (Errcode: 24 "Too many open files")')

I think this bug priority should be changed to high more because of the low limit set for the system. There are a couple of ways to do this:
/etc/security/limits.conf:
mysql soft nofile 65535
mysql hard nofile 65535

or add to the systemd unit file /usr/lib/systemd/system/mariadb.service
LimitNOFILE=65535
LimitNPROC=65535

[Tim Rozet (trozet)]

Another setting to also consider for keeping file limit low:
http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_per_table

[Damien Ciabrini (dciabrin)]

I stumbled upon the same issue a while ago when troubleshooting galera startups, so I've blogged in [1] on how mysqld* is impacted by open_files_limit=-1 and in which situation that can prevents it to set proper limits as expected.

Bottom line: we should set open_files_limit=0 as it allows mysql to use its own determined limit based on the database content. Plus, it still allows pacemaker to override the limit in the galera resource agent, when enabling HA scenarios.

[1] http://damien.ciabrini.name/posts/2016/03/troubleshooting-open_files_limit-in-mariadb.html

[Tim Rozet (trozet)]

Damien, I don't think just setting it to 0 fixes the problem. The security limits also need to change. See output below of setting to 0 does not raise above 1024 ulimit:

[root@overcloud-controller-0 ~]# grep -ir open_files_limit /etc/my.cnf.d/
/etc/my.cnf.d/galera.cnf:open_files_limit = 0
[root@overcloud-controller-0 ~]# systemctl restart mariadb
[root@overcloud-controller-0 ~]# mysql -e "SHOW VARIABLES LIKE 'open_files_limit';"
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 1024 |
+------------------+-------+
[root@overcloud-controller-0 ~]# vi /var/log/mariadb/mariadb.log
[root@overcloud-controller-0 ~]#
[root@overcloud-controller-0 ~]# cat /proc/$(pidof /usr/libexec/mysqld)/limits | grep -e Limit -e 'open files'
Limit Soft Limit Hard Limit Units
Max open files 1024 4096 files

[Damien Ciabrini (dciabrin)]

Hi Tim, sorry for the late answer,

My comment was a bit misleading, what I do mean is that open_files_limit=-1 doesn't raise in any way the file descriptor limit. In the HA case, that's rather the opposite, in that it precludes mysql (ran as root) to set the limit according the the configured max_connection parameter, for the reason explained in comment #6. consequently this return unecessary logs and confuses people.

For the non-HA case, mysql is ran by systemd as user mysql, so it cannot raise the file descriptor limit higher than the limit configured by the system. So as you pointed out in comment #4, the file descriptor limit should be raised via a systemd drop-in file.
For this specific non-HA case, I believe that drop-in file is generated automatically by puppet when run with instack-undercloud, so I think we're good already:

# cat /etc/systemd/system/mariadb.service.d/limits.conf
[Service]
LimitNOFILE=16384

When this setting is used, mysql doesn't try to raise the file descriptor limit because it's above what's necessary to run max_connection=4096 as configured. However we still see some unecessary warning in the logs, due to open_files_limit=-1 being an invalid value.

161129 10:46:47 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295
161129 10:46:47 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295

If we set open_files_limit=0 in non-HA deploy (e.g. the undercloud), _with_ the use of the drop-in systemd limit config of 16384 file descriptor, all unwanted log disappear; mysql would check if it needs to set the limits according to its needs (max_connection=4096), see that 16384 files is enough and be happy with it:

# grep files /proc/`pidof /usr/libexec/mysqld`/limits
Max open files 16384 16384 files

# mysql -e "show variables like 'max_connections';"
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 4096 |
+-----------------+-------+
# mysql -e "show variables like 'open_files_limit';"
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 16384 |
+------------------+-------+

So bottom line: open_files_limit=0 is important to let mysql set its limits when run as root (e.g. HA deployments), and is still helpful to avoid misleading warnings when used in conjunction with a systemd drop-in limit file (e.g. non-HA deployments).

[Tim Rozet (trozet)]

Damien,
For noha deployments, I do not see the LimitNOFILE set in the systemd service. I don't have this file either on my overcloud node:
[root@overcloud-controller-0 ~]# stat /etc/systemd/system/mariadb.service.d/limits.conf
stat: cannot stat ‘/etc/systemd/system/mariadb.service.d/limits.conf’: No such file or directory

This is on stable/newton deployment. That file DOES exist on the *undercloud*, however the problem remains unsolved on the overcloud. We need to set LimitNOFILE on the overcloud node as well.

[Damien Ciabrini (dciabrin)]

Oh right, I see... we also need such drop-in file in non-ha *overcloud*, you're completely right.

open_files_limit=-1 on the non-ha overcloud doesn't help to raise limit though, so my point for setting it to 0 remains valid (although incomplete as you highlighted :D)

[OpenStack Infra (hudson-openstack)]

Change abandoned by Brent Eagles (<email address hidden>) on branch: master
Review: https://review.openstack.org/255848
Reason: Abandoned due to lack of activity in the past 6 months.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/408250

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/435081

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/438600

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/438600
Committed: https://git.openstack.org/cgit/openstack/tripleo-puppet-elements/commit/?id=910a88f1ef16b63a9428f813b3ce2da918ea3aef
Submitter: Jenkins
Branch: master

commit 910a88f1ef16b63a9428f813b3ce2da918ea3aef
Author: Tim Rozet <email address hidden>
Date: Mon Feb 27 11:23:43 2017 -0500

    Adds puppet-systemd

    This puppet module is needed to manipulate systemd unit files and set
    limits needed for MariaDB.

    Partial-Bug: #1648181
    Related-Bug: #1524809

    Change-Id: I7ca7b5f7614971455cae2bf7c4bf8264b642b0dc
    Signed-off-by: Tim Rozet <email address hidden>

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/ocata
Review: https://review.openstack.org/439806

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/439806
Committed: https://git.openstack.org/cgit/openstack/tripleo-puppet-elements/commit/?id=bb18776dae74406fbf8bd49627abc24f8ad5952d
Submitter: Jenkins
Branch: stable/ocata

commit bb18776dae74406fbf8bd49627abc24f8ad5952d
Author: Tim Rozet <email address hidden>
Date: Mon Feb 27 11:23:43 2017 -0500

    Adds puppet-systemd

    This puppet module is needed to manipulate systemd unit files and set
    limits needed for MariaDB.

    Partial-Bug: #1648181
    Related-Bug: #1524809

    Change-Id: I7ca7b5f7614971455cae2bf7c4bf8264b642b0dc
    Signed-off-by: Tim Rozet <email address hidden>
    (cherry picked from commit 910a88f1ef16b63a9428f813b3ce2da918ea3aef)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/408250
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=09665170f6d0f4536a48dd4d1444e07aa064bed7
Submitter: Jenkins
Branch: master

commit 09665170f6d0f4536a48dd4d1444e07aa064bed7
Author: Damien Ciabrini <email address hidden>
Date: Wed Dec 7 19:09:06 2016 +0100

    mariadb: Move generation of systemd drop-in to puppet-tripleo

    Systemd starts mariadb as user mysql, so in order to allow a large
    number of connections (e.g. max_connections=4096) it is necessary to
    raise the file descriptor limit via a system drop-in file.

    When installing an undercloud, such drop-in file is currently
    generated by instack-undercloud (in file puppet-stack-config.pp). But
    non-HA overcloud also need such drop-in to be generated.

    In order to avoid duplicating code, the drop-in creation code should
    be provided by puppet-tripleo. By default, no drop-in is generated;
    it has to be enabled by instack-undercloud or tripleo-heat-template
    once they will use it (resp. to create undercloud or non-HA overcloud).

    This patch does not aim at generating a dynamic file limit based on
    the number of connections, this should land in another dedicated
    patch. Instead, it just reuses the limit currently set for undercloud
    and HA-overclouds.

    Also, the generation of the drop-in does not force a mysql restart
    like it currently does in instack-undercloud, to avoid unexpected
    service disruption on a non-HA overcloud after a minor update.

    Co-Authored-By: Tim Rozet <email address hidden>

    Depends-On: I7ca7b5f7614971455cae2bf7c4bf8264b642b0dc

    Change-Id: Ia0907b2ab6062a93fb9363e39c86535a490fbaf6
    Partial-Bug: #1648181
    Related-Bug: #1524809

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/ocata
Review: https://review.openstack.org/441471

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/441471
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=5d9d1c606ca9c0ddc396819f2426a00f625a3273
Submitter: Jenkins
Branch: stable/ocata

commit 5d9d1c606ca9c0ddc396819f2426a00f625a3273
Author: Damien Ciabrini <email address hidden>
Date: Wed Dec 7 19:09:06 2016 +0100

    mariadb: Move generation of systemd drop-in to puppet-tripleo

    Systemd starts mariadb as user mysql, so in order to allow a large
    number of connections (e.g. max_connections=4096) it is necessary to
    raise the file descriptor limit via a system drop-in file.

    When installing an undercloud, such drop-in file is currently
    generated by instack-undercloud (in file puppet-stack-config.pp). But
    non-HA overcloud also need such drop-in to be generated.

    In order to avoid duplicating code, the drop-in creation code should
    be provided by puppet-tripleo. By default, no drop-in is generated;
    it has to be enabled by instack-undercloud or tripleo-heat-template
    once they will use it (resp. to create undercloud or non-HA overcloud).

    This patch does not aim at generating a dynamic file limit based on
    the number of connections, this should land in another dedicated
    patch. Instead, it just reuses the limit currently set for undercloud
    and HA-overclouds.

    Also, the generation of the drop-in does not force a mysql restart
    like it currently does in instack-undercloud, to avoid unexpected
    service disruption on a non-HA overcloud after a minor update.

    Co-Authored-By: Tim Rozet <email address hidden>

    Depends-On: I7ca7b5f7614971455cae2bf7c4bf8264b642b0dc

    Change-Id: Ia0907b2ab6062a93fb9363e39c86535a490fbaf6
    Partial-Bug: #1648181
    Related-Bug: #1524809
    (cherry picked from commit 09665170f6d0f4536a48dd4d1444e07aa064bed7)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/newton
Review: https://review.openstack.org/443261

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/newton
Review: https://review.openstack.org/443312

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/443756

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/443756
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=c9acf8a687ea64686c1ecceeff45add014752121
Submitter: Jenkins
Branch: master

commit c9acf8a687ea64686c1ecceeff45add014752121
Author: Tim Rozet <email address hidden>
Date: Thu Mar 9 12:04:10 2017 -0500

    Fixes issues with raising mysql file limit

    Changes Include:
     - Adds spec testing
     - Only raise limits if nonha. puppet-systemd will restart the mariadb
       service which breaks ha deployments. Hence we only want to do this
       in noha.
     - Minor fix to hiera value refrenced not as parameter to mysql.pp

    Partial-Bug: #1648181
    Related-Bug: #1524809

    Co-Authored By: Feng Pan <email address hidden>

    Change-Id: Id063bf4b4ac229181b01f40965811cb8ac4230d5
    Signed-off-by: Tim Rozet <email address hidden>
    Signed-off-by: Feng Pan <email address hidden>

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/ocata
Review: https://review.openstack.org/447515

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/443261
Committed: https://git.openstack.org/cgit/openstack/tripleo-puppet-elements/commit/?id=47d59f4660928e03743573ce51d13e3f2e52d15a
Submitter: Jenkins
Branch: stable/newton

commit 47d59f4660928e03743573ce51d13e3f2e52d15a
Author: Tim Rozet <email address hidden>
Date: Mon Feb 27 11:23:43 2017 -0500

    Adds puppet-systemd

    This puppet module is needed to manipulate systemd unit files and set
    limits needed for MariaDB.

    Partial-Bug: #1648181
    Related-Bug: #1524809

    Change-Id: I7ca7b5f7614971455cae2bf7c4bf8264b642b0dc
    Signed-off-by: Tim Rozet <email address hidden>
    (cherry picked from commit 910a88f1ef16b63a9428f813b3ce2da918ea3aef)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/447515
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=5508557a8a7a2d193308a35f46a10041ee2403f0
Submitter: Jenkins
Branch: stable/ocata

commit 5508557a8a7a2d193308a35f46a10041ee2403f0
Author: Tim Rozet <email address hidden>
Date: Thu Mar 9 12:04:10 2017 -0500

    Fixes issues with raising mysql file limit

    Changes Include:
     - Adds spec testing
     - Only raise limits if nonha. puppet-systemd will restart the mariadb
       service which breaks ha deployments. Hence we only want to do this
       in noha.
     - Minor fix to hiera value refrenced not as parameter to mysql.pp

    Partial-Bug: #1648181
    Related-Bug: #1524809

    Co-Authored By: Feng Pan <email address hidden>

    Change-Id: Id063bf4b4ac229181b01f40965811cb8ac4230d5
    Signed-off-by: Tim Rozet <email address hidden>
    Signed-off-by: Feng Pan <email address hidden>
    (cherry picked from commit c9acf8a687ea64686c1ecceeff45add014752121)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/443312
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=094ddde297707f66b7bffb4da103e54362a658cd
Submitter: Jenkins
Branch: stable/newton

commit 094ddde297707f66b7bffb4da103e54362a658cd
Author: Damien Ciabrini <email address hidden>
Date: Wed Dec 7 19:09:06 2016 +0100

    mariadb: Move generation of systemd drop-in to puppet-tripleo

    Systemd starts mariadb as user mysql, so in order to allow a large
    number of connections (e.g. max_connections=4096) it is necessary to
    raise the file descriptor limit via a system drop-in file.

    When installing an undercloud, such drop-in file is currently
    generated by instack-undercloud (in file puppet-stack-config.pp). But
    non-HA overcloud also need such drop-in to be generated.

    In order to avoid duplicating code, the drop-in creation code should
    be provided by puppet-tripleo. By default, no drop-in is generated;
    it has to be enabled by instack-undercloud or tripleo-heat-template
    once they will use it (resp. to create undercloud or non-HA overcloud).

    This patch does not aim at generating a dynamic file limit based on
    the number of connections, this should land in another dedicated
    patch. Instead, it just reuses the limit currently set for undercloud
    and HA-overclouds.

    Also, the generation of the drop-in does not force a mysql restart
    like it currently does in instack-undercloud, to avoid unexpected
    service disruption on a non-HA overcloud after a minor update.

    Co-Authored-By: Tim Rozet <email address hidden>

    Depends-On: I7ca7b5f7614971455cae2bf7c4bf8264b642b0dc

    Change-Id: Ia0907b2ab6062a93fb9363e39c86535a490fbaf6
    Partial-Bug: #1648181
    Related-Bug: #1524809
    (cherry picked from commit 09665170f6d0f4536a48dd4d1444e07aa064bed7)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/435081
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=900ddfb27f0dd2afd8345d89a78b624f647b255d
Submitter: Jenkins
Branch: master

commit 900ddfb27f0dd2afd8345d89a78b624f647b255d
Author: Tim Rozet <email address hidden>
Date: Thu Feb 16 14:21:32 2017 -0500

    Enables increasing mariadb open files for noha deployments

    There is currently an issue where the max open files limit is hit with
    MariaDB in noha deployments, because it is defaulted to 1024 by system
    limits. In HA deployments the limit is bumped to 16384. This patch
    introduces a flag to be able to increase the limit to 16384 for noHA
    deployments.

    In the future we should change this to be an integer, and let the
    operator decide the setting. Since this setting is set in a different
    path for HA, we would need to implement a change that allows setting
    both (ha and nonha) via the same integer param.

    Depends-On: Ia0907b2ab6062a93fb9363e39c86535a490fbaf6

    Closes-Bug: #1648181
    Related-Bug: #1524809

    Change-Id: I95393fc798b833a8575afbff03ef74a839565c5e
    Signed-off-by: Tim Rozet <email address hidden>

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/ocata
Review: https://review.openstack.org/450003

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/450003
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=6b33a77f3c0bd283ec34cdc69688eede5b60949d
Submitter: Jenkins
Branch: stable/ocata

commit 6b33a77f3c0bd283ec34cdc69688eede5b60949d
Author: Tim Rozet <email address hidden>
Date: Thu Feb 16 14:21:32 2017 -0500

    Enables increasing mariadb open files for noha deployments

    There is currently an issue where the max open files limit is hit with
    MariaDB in noha deployments, because it is defaulted to 1024 by system
    limits. In HA deployments the limit is bumped to 16384. This patch
    introduces a flag to be able to increase the limit to 16384 for noHA
    deployments.

    In the future we should change this to be an integer, and let the
    operator decide the setting. Since this setting is set in a different
    path for HA, we would need to implement a change that allows setting
    both (ha and nonha) via the same integer param.

    Depends-On: Ia0907b2ab6062a93fb9363e39c86535a490fbaf6

    Closes-Bug: #1648181
    Related-Bug: #1524809

    Change-Id: I95393fc798b833a8575afbff03ef74a839565c5e
    Signed-off-by: Tim Rozet <email address hidden>
    (cherry picked from commit 900ddfb27f0dd2afd8345d89a78b624f647b255d)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/newton
Review: https://review.openstack.org/451466

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/451466
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=88a65c9676acf2ecc75ffd258fc1c6351cc22976
Submitter: Jenkins
Branch: stable/newton

commit 88a65c9676acf2ecc75ffd258fc1c6351cc22976
Author: Tim Rozet <email address hidden>
Date: Thu Mar 9 12:04:10 2017 -0500

    Fixes issues with raising mysql file limit

    Changes Include:
     - Adds spec testing
     - Only raise limits if nonha. puppet-systemd will restart the mariadb
       service which breaks ha deployments. Hence we only want to do this
       in noha.
     - Minor fix to hiera value refrenced not as parameter to mysql.pp

    Partial-Bug: #1648181
    Related-Bug: #1524809

    Co-Authored By: Feng Pan <email address hidden>

    Change-Id: Id063bf4b4ac229181b01f40965811cb8ac4230d5
    Signed-off-by: Tim Rozet <email address hidden>
    Signed-off-by: Feng Pan <email address hidden>
    (cherry picked from commit c9acf8a687ea64686c1ecceeff45add014752121)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/newton
Review: https://review.openstack.org/452803

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/452803
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=0303c83792126630eb15abed57e81261e59e9dc3
Submitter: Jenkins
Branch: stable/newton

commit 0303c83792126630eb15abed57e81261e59e9dc3
Author: Tim Rozet <email address hidden>
Date: Thu Feb 16 14:21:32 2017 -0500

    Enables increasing mariadb open files for noha deployments

    There is currently an issue where the max open files limit is hit with
    MariaDB in noha deployments, because it is defaulted to 1024 by system
    limits. In HA deployments the limit is bumped to 16384. This patch
    introduces a flag to be able to increase the limit to 16384 for noHA
    deployments.

    In the future we should change this to be an integer, and let the
    operator decide the setting. Since this setting is set in a different
    path for HA, we would need to implement a change that allows setting
    both (ha and nonha) via the same integer param.

    Depends-On: Ia0907b2ab6062a93fb9363e39c86535a490fbaf6

    Closes-Bug: #1648181
    Related-Bug: #1524809

    Change-Id: I95393fc798b833a8575afbff03ef74a839565c5e
    Signed-off-by: Tim Rozet <email address hidden>
    (cherry picked from commit 900ddfb27f0dd2afd8345d89a78b624f647b255d)

[Emilien Macchi (emilienm)]

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.

[Emilien Macchi (emilienm)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, NEWTON, OCATA, PIKE, QUEENS, QUEENS).
  Valid example: CONFIRMED FOR: FUTURE