Bug 858299 - Update error text with resolution steps: "Images cannot be built. There are no enabled Cloud Resource Provider Accounts associated with this Cloud. "
Summary: Update error text with resolution steps: "Images cannot be built. There are n...
Keywords:
Status: CLOSED EOL
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.1.0
Hardware: All
OS: Unspecified
unspecified
low
Target Milestone: rc
Assignee: Angus Thomas
QA Contact: Rehana
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-18 15:33 UTC by Aaron Weitekamp
Modified: 2020-03-27 18:05 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)
screencap: ui error text (96.45 KB, image/jpeg)
2012-09-18 15:33 UTC, Aaron Weitekamp
no flags Details

Description Aaron Weitekamp 2012-09-18 15:33:15 UTC
Created attachment 614048 [details]
screencap: ui error text

Description of problem:
When creating a new image before adding provider accounts the displayed error provides very little help to the user on how to resolve the issue.

Version-Release number of selected component (if applicable):
1.1

How reproducible:
100%

Steps to Reproduce:
1. Nav to Administer -> Clouds
2. Select New Cloud, create cloud
3. Within the cloud just created select New Cloud Resource Zone, create cloud zone 
4. Nav to Administer -> Clouds, within the cloud just created select New Image.
5. observe error
  
Actual results:
Text displayed: "Images cannot be built. There are no enabled Cloud Resource Provider Accounts associated with this Cloud."

Expected results:
Improved text: "Images cannot be built until at least one Cloud Resource Provider Account is added to this Cloud."

Comment 2 Aaron Weitekamp 2012-09-18 19:35:21 UTC
Version:
[root@qeblade41 ~]# rpm -qa |grep aeolus
aeolus-conductor-0.13.7-1.el6cf.noarch
aeolus-conductor-doc-0.13.7-1.el6cf.noarch
aeolus-all-0.13.7-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-daemons-0.13.7-1.el6cf.noarch
rubygem-aeolus-cli-0.7.1-1.el6cf.noarch
aeolus-configure-2.8.6-1.el6cf.noarch

Comment 3 Mike Orazi 2012-09-19 18:37:39 UTC
We are past string freeze, so I'll move this to 2.0.0.

Comment 4 Aaron Weitekamp 2012-09-19 18:55:42 UTC
I understood there was a compromise: validate the form and display existing message "No blueprint selected." Transcript:

Sep 18 12:49:59 <tzumainn>  aweiteka: one problem - there's no currently existing error message that fits, so creating that message would require a dictionary addition
Sep 18 12:54:07 <aweiteka>  tzumainn, forgive my ignorance... is that significant work? i can't think of another way to deal with this error.
Sep 18 12:54:36 <tzumainn>  yeah, the new dictionary addition would have to be sent to the translators
Sep 18 12:54:55 <tzumainn>  I don't know if there's time built in to do that again
Sep 18 12:56:44 <tzumainn>  there's an existing message that says "no blueprint selected"; the user would still be able to submit the form, but at least the issue would be more explicit
Sep 18 12:57:53 <aweiteka>  tzumainn, where would "no blueprint selected" be displayed? as long as they stay on the form i think that's okay for now
Sep 18 12:58:28 <tzumainn>  it would be displayed on the form, but not until they submitted it
Sep 18 12:59:41 <aweiteka>  tzumainn, that will work. it provides the basic info
Sep 18 13:00:22 <tzumainn>  okay, thanks!

Comment 5 Aaron Weitekamp 2012-09-19 19:10:58 UTC
above comment not related. ignore

Comment 6 Matt Wagner 2013-04-09 18:43:16 UTC
Resetting to default assignee; haven't looked at this in months and it's no longer on my radar.


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