Bug 741468 - hwp not matching in deployments, cant launch deployables
Summary: hwp not matching in deployments, cant launch deployables
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
Assignee: Jan Provaznik
QA Contact: wes hayutin
URL: https://10.11.230.102/conductor/deplo...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-26 22:40 UTC by wes hayutin
Modified: 2012-05-15 21:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-15 21:57:32 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:0583 0 normal SHIPPED_LIVE new packages: aeolus-conductor 2012-05-15 22:31:59 UTC

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


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