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 ---------------
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: ----------------------------
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
(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
Thanks Alan for your comment. Just to note - this bug is essentially blocking any users from successfully trying OpenStack on Fedora-19 with Packstack.
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
*** Bug 980970 has been marked as a duplicate of this bug. ***
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.
(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
There was a existing bug in puppet labs http://projects.puppetlabs.com/issues/5831 I've added pointers back to details here
(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.
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
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?
mmagr is my nickname :)
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 :)
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.
*** Bug 979018 has been marked as a duplicate of this bug. ***
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
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
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
Indeed the fix proposed in 979041 c1 works for me. Mario
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).
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
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
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
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
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
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
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
works for me, can we push to stable ?
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.
(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.
Even with openstack-packstack-2013.2.1-0.12.dev806.fc20.noarch the same issue is reproducible.
https://prod-rdojenkins.rhcloud.com/job/packstack-rdo-havana-neutron-f19-production/51/console
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?
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
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
The systemd symlink issue is bug 1014311
(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).
*** Bug 1012786 has been marked as a duplicate of this bug. ***
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
I've submitted f20 fix upstream: https://github.com/puppetlabs/puppetlabs-mysql/pull/429
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)?
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.
*** Bug 1049114 has been marked as a duplicate of this bug. ***
*** Bug 1017896 has been marked as a duplicate of this bug. ***
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
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).
I can confirm, the issue is not fixed with this update.
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
(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
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).
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
Again the same, problem does not seem fixed.
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
(In reply to Fedora Update System from comment #54) > 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 This still doesn't work, permission error on /var/log/mysqld.log doing touch /var/log/mysqld.log chown mysql:mysql /var/log/mysqld.log setenforce 0 fixes this. Should I open a separate bug for the SELinux problem here?
Any update on this? The bug described in Comment #55 prevents anyone from trying out OpenStack with packstack.
openstack-packstack-2013.2.1-0.36.dev1013.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.36.dev1013.fc20
openstack-packstack-2013.2.1-0.36.dev1013.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I'm getting what I believe is the same error on an up-to-date F21 machine, with openstack-packstack-2014.1.1-0.28.dev1238.fc21: packstack --allinone ... 128.2.16.9_amqp.pp: [ DONE ] 128.2.16.9_mysql.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 128.2.16.9_mysql.pp Error: /Stage[main]/Mysql::Config/Exec[mysqld-restart]: Failed to call refresh: service mariadb restart returned 1 instead of one of [0] You will find full trace in log /var/tmp/packstack/20150302-174938-m5egxc/manifests/128.2.16.9_mysql.pp.log Please check log file /var/tmp/packstack/20150302-174938-m5egxc/openstack-setup.log for more information # yum install mariadb-server Loaded plugins: langpacks, priorities Resolving Dependencies --> Running transaction check ---> Package mariadb-server.x86_64 1:10.0.15-4.fc21 will be installed --> Processing Conflict: 1:mariadb-galera-server-10.0.13-7.fc21.x86_64 conflicts mariadb-server --> Processing Conflict: 1:mariadb-server-10.0.15-4.fc21.x86_64 conflicts mariadb-galera-server --> Finished Dependency Resolution Error: mariadb-galera-server conflicts with 1:mariadb-server-10.0.15-4.fc21.x86_64 Error: mariadb-server conflicts with 1:mariadb-galera-server-10.0.13-7.fc21.x86_64
This problem does not appear with the current packstack package