Red Hat Bugzilla – Bug 799314
Wrong UUID is displayed in the error message
Last modified: 2014-08-17 18:27:30 EDT
Created attachment 567059 [details] UUID Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Build image to "default"cloud 2.created application blueprint to "Default" catalog (mapped to 'default"cloud) 3.Later, the default catalog was edited, mapped that to a "Private cloud" 4.Created application using this application blueprint Actual results: The application creation didnt happen as it pop ups error msg "RHEL62-vmtools: Image (UUID: 31b6f1c6-6459-11e1-802c-009027d6b9c4) belongs to the wrong environment (default) instead of Vsphere" as expected Expected results: The UUID mentioned in the error message is wrong Attached: UUID of the comp outline(PFA: UUID.png) error(error.png) Additional info:
Created attachment 567060 [details] Error [root@intel-d3c69-01 nodes]# rpm -qa | grep aeolus aeolus-conductor-doc-0.8.0-39.el6.noarch aeolus-configure-2.5.0-16.el6.noarch rubygem-aeolus-cli-0.3.0-12.el6.noarch aeolus-all-0.8.0-39.el6.noarch rubygem-aeolus-image-0.3.0-11.el6.noarch aeolus-conductor-0.8.0-39.el6.noarch aeolus-conductor-daemons-0.8.0-39.el6.noarch
Also, the term "environment" in the error message should be replaced with "Cloud"
I'm not sure this is actually incorrect. The UUID in the flash error message points to the image shown in the URL of the other page. The UUIDs shown on-page are provider-specific, but the problem is image-wide. The error message also shows the more friendly image name ("RHEL62_vmtools"), which is what I was going to propose.
I spoke a bit with Scott about this error. The conclusion is that the UUID is the correct one, but that this BZ's existence proves that the error message is unclear. I sent out http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-March/009397.html which attempts to make it a little bit clearer what is going on. The intention is to emphasize that the deployable cannot be used because of the environment mismatch, as opposed to some sort of UUID problem. I also sent a patch internally to update the product naming in the error.
Pushed to master: commit d48b71125ae6b9b4be5267a7805afad8b0d161b4 Author: Matt Wagner <matt.wagner@redhat.com> Date: Mon Mar 5 12:11:26 2012 -0500 BZ 799314 - Clarify error when a deployable has images in the wrong environment. It was unclear from the previous message what a user was to do. This attempts to clarify what has gone wrong, and tries to walk the line of giving a meaningful error that the deployable is unusable to end-users, while giving enough detail to admins that they understand what is misconfigured. Partially resolves https://bugzilla.redhat.com/show_bug.cgi?id=799314 Also on product now, with a string change for product names.
I followed the same step, observed that instance came to running state in other environment though the image was pushed to "default" cloud screen shot attached: 1. image build to default cloud (pfa: image.png) 2. running instance in private cloud zone mapped to Private cloud.(pfa: running.png) hence changing the bug status to assigned.
Created attachment 569919 [details] image
Created attachment 569925 [details] running
I'm having trouble reproducing this issue. I created a deployable in my default pool / environment, and later changed the catalog to point to another pool. I then launched the deployable contained in the catalog, and it correctly launched in the updated pool. Would you mind re-testing, and, if this is still happening, walking me through what is happening? The steps in Comment 1 result in the deployable being launched in the correct pool for me.
I am unable to reproduce the same, as the fix for this https://bugzilla.redhat.com/show_bug.cgi?id=801106 bug is expected not to edit the catalog to point a different cloud resource zone which is pointed to different cloud. Hence moving the bug status to closed.