Created fork PR: https://github.com/packstack/puppetlabs-mysql/pull/12 Created upstream PR: https://github.com/puppetlabs/puppetlabs-mysql/pull/558
I'm not certain puppet-galera (used by quickstack) needs this puppetlabs-mysql module updated. There is a manage-service flag exposed already in puppet-galera, however it looks like a refactor would be needed to allow setting the mysql root password while not managing the service https://github.com/rohara/puppet-galera/blob/3f63bd5ffdd707b42ef37a0ead3c2cf7e803586f/manifests/server.pp Ryan, what do you think?
(In reply to Crag Wolfe from comment #3) > I'm not certain puppet-galera (used by quickstack) needs this > puppetlabs-mysql module updated. It doesn't. > There is a manage-service flag exposed already in puppet-galera, however it > looks like a refactor would be needed to allow setting the mysql root > password while not managing the service > https://github.com/rohara/puppet-galera/blob/ > 3f63bd5ffdd707b42ef37a0ead3c2cf7e803586f/manifests/server.pp > > Ryan, what do you think? Right. Did some tests today with various setting for manage_service and enabled, and it is pretty much useless the way it is coded right now. I think we toss manage_service here and simply pass ensure and enabled in as params to galera::server (enabled is already there). The reason for this is that we *must* start mariadb so that we can set the root password. As the code exists right now you need manage_service set to true else nothing works at all (Service['galera'] defined in that block), and if you also have enabled set to false if will set ensure to 'stopped', which is just broken. I say we make like simple and get rid of manage service. The result is that mariadb (galera) will be started the disabled. Works for me.
Patch for puppet-galera: https://github.com/rohara/puppet-galera/commit/e35922bbb31ef2e6a86c7973cbafea96a8b160af Once this goes into o-p-m we will need to slightly modify astapor code.
Martin, can you pull the latest puppet-galera into o-p-m?
Sure, will do.
*** Bug 1134080 has been marked as a duplicate of this bug. ***
So... This change breaks when packstack runs on RHEL6 (but not RHEL7): ERROR : Error appeared during Puppet run: 172.16.32.38_mysql.pp 2014-08-26 16:46:29 Error: Duplicate declaration: Service[mysqld] is already declared in file /var/tmp/packstack/97d6c231f2894047b5b7bd6221729ca4/manifests/172.16.32.38_mysql.pp:12; cannot redeclare at /var/tmp/packstack/97d6c231f2894047b5b7bd6221729ca4/modules/mysql/manifests/server.pp:52 on node packstack.novalocal 2014-08-26 16:46:29 You will find full trace in log /var/tmp/packstack/20140826-124222-rT64an/manifests/172.16.32.38_mysql.pp.log 2014-08-26 16:46:29 Please check log file /var/tmp/packstack/20140826-124222-rT64an/openstack-setup.log for more information In packstack, there's a specific blob of puppet magic that waits for puppet to change the default mysql table type to InnoDB from MyISAM (the default on MySQL 5.1) for data consistency. Unfortunately, when the following patch is applied and run on RHEL6, it causes the above error: https://github.com/puppetlabs/puppetlabs-mysql/pull/558
Since the preferred and most up-to-date package is mariadb-galera-server (mysql 5.5 based) instead of the mysql 5.1.x as shipped with RHEL6, I believe this would imply the default database type is InnoDB, and thus, the special-case could potentially be removed.
I reopened bug 1134080 since that one's against packstack.
The problem here is not setting InnoDB as default engine, but changing parameters of InnoDB (class packstack::innodb). Unfortunately classes in currently used puppetlabs-mysql module are tightened by dependency that it will take some time to find exact mysql_install.pp template and packstack::innodb class implementation. Faster solution for that problem would be to drop manage_service patch for puppetlabs-mysql, considering puppetlabs-mysql is used only by Packstack and we don't need the patch.
Sounds like a great plan to me.