This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1025071 - improve detection of alt cloud datasources
improve detection of alt cloud datasources
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cloud-init (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Garrett Holmstrom
Fedora Extras Quality Assurance
:
: 1038792 (view as bug list)
Depends On:
Blocks: 1088496 1131374
  Show dependency treegraph
 
Reported: 2013-10-30 19:31 EDT by Matthew Miller
Modified: 2014-08-19 02:37 EDT (History)
12 users (show)

See Also:
Fixed In Version: cloud-init-0.7.2-10.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-17 00:30:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2013-10-30 19:31:54 EDT
Right now, cloud-init is failing because dmidecode doesn't exist in arm (or powerpc). This is used in one place: the get_cloud_type() method in DataSourceAltCloud (from sources/DataSourceAltCloud.py).


a) There has got to be a better way to do this. ideally, without even having the dependency.

b) the function returns one of 'RHEV', 'VSPHERE' or 'UNKNOWN'. In the interim, if dmidecode isn't found, we could just return UNKNOWN.
Comment 1 Matthew Miller 2013-10-30 19:32:53 EDT
Upstream patch to do "b": https://bugs.launchpad.net/qemu/+bug/1243287
Comment 2 Matthew Miller 2013-12-09 11:08:48 EST
*** Bug 1038792 has been marked as a duplicate of this bug. ***
Comment 3 Gustavo Luiz Duarte 2014-01-28 12:21:43 EST
"b" won't work either, given the issue is not on runtime, but during dependency resolution.

mator suggested on IRC:
c) we could use virt-what: http://people.redhat.com/~rjones/virt-what/


It seems a better solution than requiring dmidecode explicitly and it is available on Fedora for all arches.
Comment 4 Matthew Miller 2014-01-28 13:04:27 EST
(In reply to Gustavo Luiz Duarte from comment #3)
> "b" won't work either, given the issue is not on runtime, but during
> dependency resolution.

Sure it will. I mean, there are some implicit packaging changes implied, but I don't see a big deal. Simply either make cloud-init archful and make the Requires conditional on arch, or don't hard-require dmidecode at all and just make sure it is in the package set on architectures where it is useful.

virt-what just adds a layer of indirection to the problem, because it's just a shell script which uses dmidecode as well. (And which already fails gracefully.)
Comment 5 Matthew Miller 2014-01-28 13:05:20 EST
In fact, from the virt-what specfile:

# virt-what script uses dmidecode and getopt (from util-linux).
# RPM cannot detect this so make the dependencies explicit here.
%ifarch %{ix86} x86_64
Requires:       dmidecode
%endif
Comment 6 Gustavo Luiz Duarte 2014-01-28 13:23:54 EST
(In reply to Matthew Miller from comment #4)
> Sure it will. I mean, there are some implicit packaging changes implied, but
> I don't see a big deal. Simply either make cloud-init archful and make the
> Requires conditional on arch, or don't hard-require dmidecode at all and
> just make sure it is in the package set on architectures where it is useful.

Right. I was just assuming that the cloud-init maintainer doesn't want to make it archful based on https://bugzilla.redhat.com/show_bug.cgi?id=1038792#c1
(only now I checked it and figured you are also a maintainer, so nevermind ;) )

Using virt-what does add a layer of indirection but also has better support for other hypervisors and avoids code duplication. Anyway, I'm fine with either solution as long we get cloud-init available for all arches.

What we need here? Writing a patch doesn't seem too much effort. If you want I can try to write a patch to implement "b".
Comment 7 Matthew Miller 2014-03-05 17:25:25 EST
Upstream fix:

https://bugs.launchpad.net/cloud-init/+bug/1285686
Comment 8 Brent Baude 2014-03-28 10:11:59 EDT
Can we pull this into Fedora then?
Comment 9 Gustavo Luiz Duarte 2014-04-30 17:57:16 EDT
Could we please make cloud-init archful, as Matthew suggested on comment 4 ?

Here is a patch to do that:

diff --git a/cloud-init.spec b/cloud-init.spec
index 24a8b21..b6701fe 100644
--- a/cloud-init.spec
+++ b/cloud-init.spec
@@ -20,13 +20,14 @@ Patch0:         cloud-init-0.7.5-fedora.patch
 Patch1:         cloud-init-0.7.5-rsyslog-programname.patch
 
 
-BuildArch:      noarch
 BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildRequires:  python-devel
 BuildRequires:  python-setuptools-devel
 BuildRequires:  systemd-units
+%ifarch %{ix86} x86_64 ia64
 Requires:       dmidecode
+%endif
 Requires:       e2fsprogs
 Requires:       iproute
 Requires:       libselinux-python
Comment 10 Fedora Update System 2014-06-09 16:30:32 EDT
cloud-init-0.7.2-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/cloud-init-0.7.2-10.fc20
Comment 11 Fedora Update System 2014-06-09 16:32:20 EDT
cloud-init-0.7.2-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cloud-init-0.7.2-10.fc19
Comment 12 Fedora Update System 2014-06-11 12:24:29 EDT
Package cloud-init-0.7.2-10.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 cloud-init-0.7.2-10.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7238/cloud-init-0.7.2-10.fc19
then log in and leave karma (feedback).
Comment 13 Fedora Update System 2014-07-17 00:28:26 EDT
cloud-init-0.7.2-10.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2014-07-17 00:30:54 EDT
cloud-init-0.7.2-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.