Bug 1077757

+++ This bug was initially created as a clone of Bug #981116 +++

Description of problem: With Fedora 19's switch to maridb-server, packstack fails with a dependency that it can't find mysql-server (although mariadb-server has a virtual "Provides" of mysql-server).

---------------
$ cat /etc/redhat-release 
Fedora release 19 (Schrödinger’s Cat)


$ packstack --allinone                                
.
.
.
ERROR : Error during puppet run : Error: Could not find package mysql-server
Please check log file /var/tmp/packstack/20130704-003848-W2ATsO/openstack-setup.log for more information
---------------


-> mariadb-server is installed:
---------------
$ rpm -q mariadb-server
mariadb-server-5.5.31-4.fc19.x86_64
---------------


-> mariadb spec file "Provides" mysql-server:
---------------
  $ fedpkg clone -B -a mariadb
  $ cd mariadb/f19
  $ grep mysql-server mariadb.spec 
  Provides: mysql-server = %{epoch}:%{version}-%{release}
  Provides: mysql-server%{?_isa} = %{epoch}:%{version}-%{release}
  Conflicts: community-mysql-server
  Obsoletes: mysql-server < %{obsoleted_mysql_evr}
  %triggerun server -- mysql-server
---------------

--- Additional comment from Kashyap Chamarthy on 2013-07-04 00:57:39 EDT ---

Just grepped through packstack sources, probably most instances of mysqldb-server should be renamed to mariadb-server?
----------------------------

$ git clone https://github.com/stackforge/packstack.git
$ grep -r mysql-server *
packstack/puppet/modules/mysql/manifests/params.pp:      $server_package_name   = 'mysql-server'
packstack/puppet/modules/mysql/manifests/params.pp:      $server_package_name  = 'mysql-server'
packstack/puppet/modules/mysql/manifests/params.pp:      $service_name          = 'mysql-server'
packstack/puppet/modules/mysql/manifests/params.pp:          $server_package_name   = 'mysql-server'
packstack/puppet/modules/mysql/manifests/server/config.pp:    require => Package['mysql-server'],
packstack/puppet/modules/mysql/manifests/server.pp:  package { 'mysql-server':
packstack/puppet/modules/mysql/manifests/server.pp:      require  => Package['mysql-server'],
packstack/puppet/modules/mysql/spec/classes/mysql_server_spec.rb:      :require  => 'Package[mysql-server]'
packstack/puppet/modules/mysql/spec/classes/mysql_server_spec.rb:        :package_name => 'mysql-server'
packstack/puppet/modules/mysql/spec/classes/mysql_server_spec.rb:        :service_name => 'mysql-server',
packstack/puppet/modules/mysql/spec/classes/mysql_server_spec.rb:        :package_name => 'mysql-server'
packstack/puppet/modules/mysql/spec/classes/mysql_server_spec.rb:            it { should contain_package('mysql-server').with(
packstack/puppet/modules/mysql/spec/classes/mysql_server_spec.rb:                  :require => 'Package[mysql-server]'
packstack/puppet/modules/mysql/spec/classes/mysql_config_spec.rb:         :service_name => 'mysql-server',
packstack/puppet/modules/mysql/spec/defines/mysql_server_config_spec.rb:  it 'should require on the mysql-server package' do
packstack/puppet/modules/mysql/spec/defines/mysql_server_config_spec.rb:    should contain_file(filename).with_require('Package[mysql-server]')
packstack/puppet/modules/mysql/README.md:Installs mysql-server packages, configures my.cnf and starts mysqld service:
----------------------------

--- Additional comment from Sandro Mathys on 2013-07-04 01:38:42 EDT ---

Clearly the params.pp needs to be patched (in a little more sophisticated ways than just s/mysql/mariadb/ ) in the upstream mysql module (and be backported to Packstack's fork if the fork is still necessary and otherwise drop it). Nothing more should be necessary as it's very portable code.

Oh, and the Provides: mysql-server is not good enough because Puppet's rpm Package Provider is doing things in...uhm...special ways, for good or bad. Either way, a lot of other options would probably be wrong, too as you can see:
https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params.pp

--- Additional comment from Alan Pevec on 2013-07-04 04:11:36 EDT ---

(In reply to Sandro Mathys from comment #2)
> Puppet's rpm Package Provider is doing things in...uhm...special ways, for good or bad.

For bad, IMHO: Puppet's rpm Package Provider should be fixed, it seems to be doing rpm -qa which doesn't include virtual RPM provides.

The same issue was with qemu-kvm-rhev in RHOS so I'm repeating needinfo from bug 971801 comment 3

--- Additional comment from Kashyap Chamarthy on 2013-07-04 04:25:56 EDT ---

Thanks Alan for your comment.

Just to note - this bug is essentially blocking any users from successfully trying OpenStack on Fedora-19 with Packstack.

--- Additional comment from Pádraig Brady on 2013-07-04 04:39:30 EDT ---

puppet should be changed to do something equiv to:
  rpm -q --whatprovides mysql-server

A similar change was made to openstack-db recently:
  https://github.com/redhat-openstack/openstack-utils/commit/f7beaa18

--- Additional comment from Sandro Mathys on 2013-07-04 08:54:17 EDT ---



--- Additional comment from Sandro Mathys on 2013-07-05 05:04:47 EDT ---

Sent a pull request which hopefully fixes the issue at hand to upstream of puppetlabs-mysql:
https://github.com/puppetlabs/puppetlabs-mysql/pull/210

Once it's been accepted there I'll send another pull request to packstack's fork if the fork is still considered necessary.

--- Additional comment from Derek Higgins on 2013-07-05 05:25:25 EDT ---

(In reply to Alan Pevec from comment #3)
> (In reply to Sandro Mathys from comment #2)
> > Puppet's rpm Package Provider is doing things in...uhm...special ways, for good or bad.
> 
> For bad, IMHO: Puppet's rpm Package Provider should be fixed, it seems to be
> doing rpm -qa which doesn't include virtual RPM provides.
> 
> The same issue was with qemu-kvm-rhev in RHOS so I'm repeating needinfo from
> bug 971801 comment 3

Yup, the long term solution here would be a fix to puppets rpm provider, if it not reported already we should report it. I'll do a search and see if I can find an existing bug

(In reply to Sandro Mathys from comment #7)
> Sent a pull request which hopefully fixes the issue at hand to upstream of
> puppetlabs-mysql:
> https://github.com/puppetlabs/puppetlabs-mysql/pull/210

looks good to me, thanks

> 
> Once it's been accepted there I'll send another pull request to packstack's
> fork if the fork is still considered necessary.

As far as I can see the fork was taken so that the root home dir wasn't hardcoded
https://github.com/packstack/puppetlabs-mysql/commit/234dde359582e9f1e52b218da7eeece245c2e86f

This was also submitted to puppetlabs at the time, but as yet hasn't been merged (but started to see a little movment this week)
https://github.com/puppetlabs/puppetlabs-mysql/pull/153

looks like mmagr will be updating it next week when he is back

--- Additional comment from Derek Higgins on 2013-07-05 06:01:08 EDT ---

There was a existing bug in puppet labs
http://projects.puppetlabs.com/issues/5831

I've added pointers back to details here

--- Additional comment from Sandro Mathys on 2013-07-05 14:02:38 EDT ---

(In reply to Derek Higgins from comment #8)
> (In reply to Alan Pevec from comment #3)
> > (In reply to Sandro Mathys from comment #2)
> > > Puppet's rpm Package Provider is doing things in...uhm...special ways, for good or bad.
> > 
> > For bad, IMHO: Puppet's rpm Package Provider should be fixed, it seems to be
> > doing rpm -qa which doesn't include virtual RPM provides.
> > 
> > The same issue was with qemu-kvm-rhev in RHOS so I'm repeating needinfo from
> > bug 971801 comment 3
> 
> Yup, the long term solution here would be a fix to puppets rpm provider, if
> it not reported already we should report it. I'll do a search and see if I
> can find an existing bug
> 
> (In reply to Sandro Mathys from comment #7)
> > Sent a pull request which hopefully fixes the issue at hand to upstream of
> > puppetlabs-mysql:
> > https://github.com/puppetlabs/puppetlabs-mysql/pull/210
> 
> looks good to me, thanks

So that's been merged already now.

> > 
> > Once it's been accepted there I'll send another pull request to packstack's
> > fork if the fork is still considered necessary.
> 
> As far as I can see the fork was taken so that the root home dir wasn't
> hardcoded
> https://github.com/packstack/puppetlabs-mysql/commit/
> 234dde359582e9f1e52b218da7eeece245c2e86f
> 
> This was also submitted to puppetlabs at the time, but as yet hasn't been
> merged (but started to see a little movment this week)
> https://github.com/puppetlabs/puppetlabs-mysql/pull/153
> 
> looks like mmagr will be updating it next week when he is back

Figure if the fork is obsolete by next week (and I figure no new rpm would be built to fix this bug without mmagr anyway), I don't need to send you another pull request. Let me know if you'd still rather get one, though.

--- Additional comment from Mario Ceresa on 2013-07-08 05:41:36 EDT ---

Hello all,
I have a small openstack installation that got struck by this problem. Nothing vital, but it would be nice to get it working again :). Is there any timeframe/fix/way I could help with this?

Thanks and regards,

Mario

--- Additional comment from Mario Ceresa on 2013-07-08 12:04:20 EDT ---

Thanks Martin,
now I see the fix was already merged upstream. I'll wait for the updated rpm than.

Thanks a lot,

Mario

PS: @Sandro, what is mmagr?

--- Additional comment from Martin Magr on 2013-07-08 14:08:54 EDT ---

mmagr is my nickname :)

--- Additional comment from Mario Ceresa on 2013-07-08 16:43:50 EDT ---

Hehehehehe and I thought it was some weird dependency. I must be totally blind: I had your email right in front of my eyes the entire time :)

--- Additional comment from Sandro Mathys on 2013-07-10 04:02:28 EDT ---

FWIW, mmagr's pull request has now also been merged, i.e. the puppetlabs-mysql fork can probably be dropped from packstack in favor of upstream.

--- Additional comment from Martin Magr on 2013-07-10 12:57:51 EDT ---



--- Additional comment from ryo fujita on 2013-07-10 21:17:10 EDT ---

FYI.

'coomunity-mysql-server' is installed with 'mariadb-libs' because 'community-mysql-server' requires 'perl-DBD-MySQL' and 'perl-DBD-MySQL' requires 'mariadb' not 'mysql' nor 'community-mysql'.

From perl-DBD-MySQL.spec

BuildRequires:  mariadb, mariadb-devel, zlib-devel

It should be fixed as follows.

BuildRequires:  mysql, mysql-devel, zlib-devel

or

BuildRequires:  community-mysql, community-mysql-devel, zlib-devel

--- Additional comment from Fedora Update System on 2013-07-11 05:19:06 EDT ---

openstack-packstack-2013.1.1-0.20.dev642.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.20.dev642.fc19

--- Additional comment from Mario Ceresa on 2013-07-11 10:13:11 EDT ---


Hi Martin, thanks for the update. Everything went smooth with mariadb. But now I hit:

Stage[main]//Exec[load_kvm]/returns: change from notrun to 0 failed: /bin/sh: /etc/sysconfig/modules/kvm.modules: No such file or directory

when applying nova.pp to a node.

I'm not sure if it has something to do with:
https://bugzilla.redhat.com/show_bug.cgi?id=963198
https://bugzilla.redhat.com/show_bug.cgi?id=979041

Thanks,

Mario

--- Additional comment from Mario Ceresa on 2013-07-11 10:28:49 EDT ---

Indeed the fix proposed in 979041 c1 works for me.

Mario

--- Additional comment from Fedora Update System on 2013-07-11 22:59:51 EDT ---

Package openstack-packstack-2013.1.1-0.20.dev642.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openstack-packstack-2013.1.1-0.20.dev642.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-12773/openstack-packstack-2013.1.1-0.20.dev642.fc19
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2013-07-25 03:19:58 EDT ---

openstack-packstack-2013.1.1-0.21.dev651.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.21.dev651.fc19

--- Additional comment from Fedora Update System on 2013-08-01 06:52:13 EDT ---

openstack-packstack-2013.1.1-0.22.dev653.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.22.dev653.fc19

--- Additional comment from Fedora Update System on 2013-08-09 03:08:11 EDT ---

openstack-packstack-2013.1.1-0.23.dev657.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.23.dev657.fc19

--- Additional comment from Fedora Update System on 2013-08-13 13:39:05 EDT ---

openstack-packstack-2013.1.1-0.24.dev660.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.24.dev660.fc19

--- Additional comment from Fedora Update System on 2013-08-19 12:24:34 EDT ---

openstack-packstack-2013.1.1-0.25.dev672.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.25.dev672.fc19

--- Additional comment from Fedora Update System on 2013-08-19 12:34:56 EDT ---

openstack-packstack-2013.1.1-0.26.dev672.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.26.dev672.fc19

--- Additional comment from Fedora Update System on 2013-08-19 12:48:23 EDT ---

openstack-packstack-2013.1.1-0.27.dev672.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.1.1-0.27.dev672.fc19

--- Additional comment from Itamar Reis Peixoto on 2013-08-21 11:17:35 EDT ---

works for me, can we push to stable ?

--- Additional comment from Fedora Update System on 2013-08-22 20:30:08 EDT ---

openstack-packstack-2013.1.1-0.27.dev672.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from K. Gao on 2013-09-10 04:30:29 EDT ---

(In reply to Fedora Update System from comment #30)
> openstack-packstack-2013.1.1-0.27.dev672.fc19 has been pushed to the Fedora
> 19 stable repository.  If problems still persist, please make note of it in
> this bug report.

I'm working with openstack-packstack-2013.1.1-0.28.dev677.fc19.noarch but still suffering this issue.

--- Additional comment from sudeesh john on 2013-11-11 23:53:59 EST ---

Even with openstack-packstack-2013.2.1-0.12.dev806.fc20.noarch the same issue is reproducible.

--- Additional comment from wes hayutin on 2013-11-14 14:39:31 EST ---

https://prod-rdojenkins.rhcloud.com/job/packstack-rdo-havana-neutron-f19-production/51/console

--- Additional comment from Pádraig Brady on 2013-11-14 14:44:21 EST ---

Note that the CI runs at:
https://prod-rdojenkins.rhcloud.com/job/packstack-rdo-havana-neutron-f19-production/

These have only noticed 'Error: Could not find package mysql-devel;' today.

openstack-packstack has stayed at version 2013.2.1-0.12.dev806

So it seems like something outside packstack has changed,
that packstack might need adjusting to handle?

--- Additional comment from Pádraig Brady on 2014-01-06 08:17:29 EST ---

Same issue with mysql.pp in openstack-packstack-2013.2.1-0.27.dev936 on Fedora 20.

packstack is trying to run: /sbin/chkconfig mysqld on
which is no longer supported it seems:

  Note: Forwarding request to 'systemctl enable mysqld.service'.
  Failed to issue method call: No such file or directory

--- Additional comment from Pádraig Brady on 2014-01-06 08:33:43 EST ---

This looks like a systemd change?

mariadb provides the compat service link:
# ll /usr/lib/systemd/system/mysqld.service
lrwxrwxrwx. 1 root root 15 Jan  6 12:57 /usr/lib/systemd/system/mysqld.service -> mariadb.service

and systemd even looks it up successfully?
# strace -e file systemctl enable mysqld.service
...
access("/usr/lib/systemd/system/mysqld.service", F_OK) = 0
Failed to issue method call: No such file or directory

Indeed if I change the symlink to a file copy, it works OK?

So workaround is:

rm /usr/lib/systemd/system/mysqld.service
cp /usr/lib/systemd/system/mariadb.service /usr/lib/systemd/system/mysqld.service

--- Additional comment from Pádraig Brady on 2014-01-07 11:55:26 EST ---

The systemd symlink issue is bug 1014311

--- Additional comment from Honza Horak on 2014-01-10 11:56:17 EST ---

(In reply to Pádraig Brady from comment #36)
> rm /usr/lib/systemd/system/mysqld.service
> cp /usr/lib/systemd/system/mariadb.service
> /usr/lib/systemd/system/mysqld.service

If you cannot adopt mariadb.service file name for setups in F20+, I'd suggest at least copy to /etc/systemd/system/mysqld.service, where user's service files belong. Otherwise the file would be rewritten after next update (if I'm not mistaken; didn't tested).

--- Additional comment from Pádraig Brady on 2014-01-15 17:01:40 EST ---



--- Additional comment from Martin Magr on 2014-01-23 08:32:59 EST ---

Pádraig, looking at openstack-packstack-2013.2.1-0.29.dev956.fc20 build [1] there is the MariaDB patch changing the service name to mariadb, so IMHO this is fixed. Also I was not able to reproduce your issue with the build.

About the mysql-devel issue: it's caused by puppet-tempest module. Luckily, there's already patch for that in upstream, so only module update is necessary.


[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=490764

--- Additional comment from Martin Magr on 2014-01-24 11:04:41 EST ---

I've submitted f20 fix upstream: https://github.com/puppetlabs/puppetlabs-mysql/pull/429

--- Additional comment from Lars Kellogg-Stedman on 2014-01-28 16:07:23 EST ---

martin: do you have any idea if these fixes will hit our RDO icehouse packages in advance of the next rdo test days (2/4 and 2/5)?

--- Additional comment from Martin Magr on 2014-01-30 07:49:23 EST ---

If you are asking about fix from comment 41 then it is already in packstack's dev956.fc20 build. Updated puppet-tempest will be in next fc20 build.

--- Additional comment from Martin Magr on 2014-01-30 07:56:29 EST ---



--- Additional comment from Martin Magr on 2014-02-05 05:46:51 EST ---



--- Additional comment from Fedora Update System on 2014-02-07 05:35:46 EST ---

openstack-packstack-2013.2.1-0.30.dev979.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.30.dev979.fc20

--- Additional comment from Fedora Update System on 2014-02-08 00:05:20 EST ---

Package openstack-packstack-2013.2.1-0.30.dev979.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openstack-packstack-2013.2.1-0.30.dev979.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2162/openstack-packstack-2013.2.1-0.30.dev979.fc20
then log in and leave karma (feedback).

--- Additional comment from Matthias Runge on 2014-02-17 09:34:20 EST ---

I can confirm, the issue is not fixed with this update.

--- Additional comment from Fedora Update System on 2014-02-21 13:25:44 EST ---

openstack-packstack-2013.2.1-0.31.dev982.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.31.dev982.fc20

--- Additional comment from Pablo Hinojosa on 2014-02-22 09:52:03 EST ---

(In reply to Fedora Update System from comment #49)
> openstack-packstack-2013.2.1-0.31.dev982.fc20 has been submitted as an
> update for Fedora 20.
> https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.31.
> dev982.fc20

http://pastebin.com/1nsUTH8E

ERROR : Error appeared during Puppet run: 192.168.122.30_mysql.pp
Error: Could not find package mysql

with 
[root@localhost ~]# yum list installed | grep packstack
openstack-packstack.noarch      2013.2.1-0.31.dev982.fc20
                                                    @/openstack-packstack-2013.2.1-0.31.dev982.fc20.noarch
packstack-modules-puppet.noarch 2013.2.1-0.31.dev982.fc20
                                                    @/packstack-modules-puppet-2013.2.1-0.31.dev982.fc20.noarch

--- Additional comment from Fedora Update System on 2014-02-22 13:07:10 EST ---

Package openstack-packstack-2013.2.1-0.31.dev982.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openstack-packstack-2013.2.1-0.31.dev982.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2885/openstack-packstack-2013.2.1-0.31.dev982.fc20
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2014-02-26 09:28:13 EST ---

openstack-packstack-2013.2.1-0.32.dev987.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.32.dev987.fc20

--- Additional comment from Pablo Hinojosa on 2014-02-26 11:47:45 EST ---

Again the same, problem does not seem fixed.

--- Additional comment from Fedora Update System on 2014-03-07 06:36:50 EST ---

openstack-packstack-2013.2.1-0.34.dev989.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.34.dev989.fc20