Bug 741468

Summary: hwp not matching in deployments, cant launch deployables
Product: [Retired] CloudForms Cloud Engine Reporter: wes hayutin <whayutin>
Component: aeolus-conductorAssignee: Jan Provaznik <jprovazn>
Status: CLOSED ERRATA QA Contact: wes hayutin <whayutin>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 1.0.0CC: athomas, dajohnso, deltacloud-maint, jprovazn, slinaber, ssachdev
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://10.11.230.102/conductor/deployments/new
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-15 21:57:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description wes hayutin 2011-09-26 22:40:50 UTC
error:
Some assemblies will not be launched:	
frontend: Hardware Profile default not found.


  HardwareProfile Load (0.6ms)  SELECT "hardware_profiles".* FROM "hardware_profiles" WHERE "hardware_profiles"."provider_id" IS NULL AND "hardware_profiles"."name" = 'default' LIMIT 1



s" LEFT OUTER JOIN "roles" ON "roles"."id" = "permissions"."role_id" LEFT OUTER JOIN "privileges" ON "privileges"."role_id" = "roles"."id" WHERE ("permissions".permission_object_id = 1 AND "permissions".permission_object_type = 'Pool') AND (permissions.user_id=1 and
 privileges.target_type='Deployment' and
 privileges.action='create')) AS id_list ORDER BY id_list.alias_0 LIMIT 1
  Permission Load (0.7ms)  SELECT "permissions"."id" AS t0_r0, "permissions"."role_id" AS t0_r1, "permissions"."user_id" AS t0_r2, "permissions"."permission_object_id" AS t0_r3, "permissions"."permission_object_type" AS t0_r4, "permissions"."lock_version" AS t0_r5, "permissions"."created_at" AS t0_r6, "permissions"."updated_at" AS t0_r7, "roles"."id" AS t1_r0, "roles"."name" AS t1_r1, "roles"."scope" AS t1_r2, "roles"."lock_version" AS t1_r3, "roles"."created_at" AS t1_r4, "roles"."updated_at" AS t1_r5, "roles"."assign_to_owner" AS t1_r6, "privileges"."id" AS t2_r0, "privileges"."role_id" AS t2_r1, "privileges"."target_type" AS t2_r2, "privileges"."action" AS t2_r3, "privileges"."lock_version" AS t2_r4, "privileges"."created_at" AS t2_r5, "privileges"."updated_at" AS t2_r6 FROM "permissions" LEFT OUTER JOIN "roles" ON "roles"."id" = "permissions"."role_id" LEFT OUTER JOIN "privileges" ON "privileges"."role_id" = "roles"."id" WHERE "permissions"."id" IN (1) AND ("permissions".permission_object_id = 1 AND "permissions".permission_object_type = 'Pool') AND (permissions.user_id=1 and
 privileges.target_type='Deployment' and
 privileges.action='create') ORDER BY permissions.id ASC
  HardwareProfile Load (0.6ms)  SELECT "hardware_profiles".* FROM "hardware_profiles" WHERE "hardware_profiles"."provider_id" IS NULL AND "hardware_profiles"."name" = 'default' LIMIT 1
Rendered layouts/_nav_history.haml (0.5ms)
Rendered layouts/_filter_table.haml (4.1ms)
Rendered deployments/_new.haml (158.5ms)
Rendered layouts/_masthead.haml (2.4ms)
Rendered layouts/_new_notification.haml (1.1ms)
Rendered deployments/new.haml within layouts/application (177.6ms)
Completed 200 OK in 256ms (Views: 178.8ms | ActiveRecord: 5.3ms)
  SQL (0.3ms)  SHOW client_min_messages
  SQL (0.1ms)  SET client_min_messages TO 'panic'
  SQL (0.1ms)  SET standard_conforming_strings = on
  SQL (0.1ms)  SET client_min_messages TO 'notice'
  SQL (0.4ms)  SET time zone 'UTC'
  SQL (0.1ms)  SHOW TIME ZONE
  Pool Load (1.0ms)  SELECT "pools".* FROM "pools"
  Instance Load (0.9ms)  SELECT "instances".* FROM "instances" WHERE ("instances".pool_id = 1)

DB*************************************
conductor=# select * from hardware_profiles;
 id | external_key |  name   | memory_id | storage_id | cpu_id | architecture_id | provider_id | lock_version |         created_at         
|         updated_at         
----+--------------+---------+-----------+------------+--------+-----------------+-------------+--------------+----------------------------
+----------------------------
  1 |              | hwp2    |         1 |          2 |      3 |               4 |             |            0 | 2011-09-26 21:20:43.168567 
| 2011-09-26 21:20:43.168567
  2 |              | hwp1    |         5 |          6 |      7 |               8 |             |            0 | 2011-09-26 21:20:43.532509 
| 2011-09-26 21:20:43.532509
  3 | default      | default |         9 |         10 |     11 |              12 |           4 |            0 | 2011-09-26 22:08:01.199759 
| 2011-09-26 22:08:01.199759
(3 rows)


[root@unused ~]# rpm -qa | grep aeolus
aeolus-conductor-0.4.0-0.20110926211730git1cc372b.fc15.noarch
aeolus-conductor-daemons-0.4.0-0.20110926211730git1cc372b.fc15.noarch
aeolus-all-0.4.0-0.20110926211730git1cc372b.fc15.noarch
aeolus-conductor-doc-0.4.0-0.20110926211730git1cc372b.fc15.noarch
aeolus-conductor-devel-0.4.0-0.20110926211730git1cc372b.fc15.noarch
rubygem-aeolus-image-0.1.0-3.20110919115936gitd1d24b4.fc15.noarch
aeolus-configure-2.0.2-4.20110926142838git5044e56.fc15.noarch

Comment 1 Jan Provaznik 2011-09-27 10:54:42 UTC
There are two kinds of HW profiles in conductor:
- frontend HW profiles - profiles exposed to uesers in UI, users can define various frontend HW profiles, these profiles are then mapped to real/backend HW profiles when launching an instance
- backend HW profiles - real hw profiles fetched from cloud providers

Both frontend and backend profiles are saved in table "hardware_profiles", only idfference is that frontend profiles don't have provider_id.

From output above, it seems that there is really not 'default' hardware profile. There is only _backend_ hw profile (it has provider_id 4), named 'default' (probably fetched from vsphere driver?).

You can check if there is frontend HW profile by checking HW profiles list in web UI as admin user.

Comment 2 Jan Provaznik 2011-09-27 13:09:50 UTC
It turned out that problem is that in new admin UI are displayed backend profiles instead of frontend profiles so hw profile loading in providers controller needs to be fixed -> switching to Jirka as he works on this now.

Comment 3 Jan Provaznik 2011-09-27 13:54:26 UTC
Sorry for spamming, reassigning back to me - going to do some hotfix for this.

Comment 4 wes hayutin 2011-09-28 16:38:42 UTC
making sure all the bugs are at the right version for future queries

Comment 6 Jan Provaznik 2011-10-07 13:55:55 UTC
this should be already fixed in current master branch, I think it is commit 32c2f0a1d3f6615f304b608bb9468cd6c7f8aa31

Comment 7 Steve Linabery 2011-10-07 17:10:11 UTC
setting to ON_QA on weshay's advice. I don't know what commit is 32c2f0a1d3f6615f304b608bb9468cd6c7f8aa31; I do not see that in conductor git log.

Comment 8 wes hayutin 2011-10-11 14:24:40 UTC
verified in 0.4.0 build

Comment 9 wes hayutin 2011-10-11 14:29:11 UTC
taking off tracker

Comment 11 errata-xmlrpc 2012-05-15 21:57:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0583.html