Hide Forgot
Created attachment 566219 [details] Environment Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Log in to conductor 2.go to comp. outline 3.verify the table header of the comp. outline(screen shot, Environment.png) Actual results: Expected results: Environment should be changed to cloud Additional info: [root@intel-d3c69-01 ~]# rpm -qa | grep aeolus aeolus-conductor-0.8.0-36.el6.noarch aeolus-conductor-daemons-0.8.0-36.el6.noarch rubygem-aeolus-image-0.3.0-10.el6.noarch rubygem-aeolus-cli-0.3.0-10.el6.noarch aeolus-all-0.8.0-36.el6.noarch aeolus-conductor-doc-0.8.0-36.el6.noarch aeolus-configure-2.5.0-15.el6.noarch
agreed.. 1. Any notion of "environment" in the webui should be called "cloud" for consistency. 2. In the CLI we are using "environment", I was shot down by sseago to change the cli, but IMHO still think it should be changed to "cloud"
On point 1, we should indeed replace "Environment" to "Cloud" in the column heading, in order to consistently use the Cloud Engine names.
Patch sent for #1; internal since the naming change would not be applicable upstream. I'd propose that this BZ relate to #1 only. #2 is in a different application.
This has been ACKed, but I was asked to not push to this repo just yet, so I'm in a holding pattern on this.
For point 2, we should not switch the cli. While it leads to slight inconsistency in presentation between the cli and conductor it would also lead to code to a case where we would not reliably be able to apply upstream changes to the cli in future.
(In reply to comment #5) > For point 2, we should not switch the cli. While it leads to slight > inconsistency in presentation between the cli and conductor it would also lead > to code to a case where we would not reliably be able to apply upstream changes > to the cli in future. why? does upstream not like the term cloud? The cli could be aliased to use either term.. We need consistency through out the app. Its important enough to reconsider a better way to get there and not accept a difficult to understand product.
(In reply to comment #6) > (In reply to comment #5) > > For point 2, we should not switch the cli. While it leads to slight > > inconsistency in presentation between the cli and conductor it would also lead > > to code to a case where we would not reliably be able to apply upstream changes > > to the cli in future. > > why? does upstream not like the term cloud? > The cli could be aliased to use either term.. We need consistency through out > the app. Its important enough to reconsider a better way to get there and not > accept a difficult to understand product. The name 'Cloud' (and the whole of the product names, really) were NACKed upstream. Our attempts to work towards a common set of names got nowhere. I strongly agree that we need to work towards a common set of names, but the right solution is definitely not using the NACKed names upstream. In any event, can we move this discussion somewhere other than the comments of this semi-unrelated bug? I'm going to push a fix for #1 here and mark this as MODIFIED and don't want the discussion to get lost.
On 1.0-product: commit 74ff94af030fd9d3e6b941c8bc6dd07212b4ae45 Author: Matt Wagner <matt.wagner> Date: Tue Feb 28 17:09:22 2012 -0500 BZ 798136 - Fix reference to 'Environment' The key was missing from en.yml entirely. Resolves https://bugzilla.redhat.com/show_bug.cgi?id=798136
The term "Environment" is changed to "Cloud" in the Component Outline. see attached screenshot. A separate bug https://bugzilla.redhat.com/show_bug.cgi?id=802611 is logged to track point 2 from comment 1. verified: rpm -qa | grep aeolus rubygem-aeolus-cli-0.3.0-13.el6.noarch aeolus-conductor-0.8.0-41.el6.noarch aeolus-configure-2.5.0-18.el6.noarch aeolus-conductor-doc-0.8.0-41.el6.noarch aeolus-all-0.8.0-41.el6.noarch aeolus-conductor-daemons-0.8.0-41.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch
Created attachment 569549 [details] ref
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