Bug 619248 - Apache Connection props not populated/specified anywhere after upgrading 2.3.1 -> 2.4 in some circumstances
Summary: Apache Connection props not populated/specified anywhere after upgrading 2.3....
Keywords:
Status: CLOSED DUPLICATE of bug 573034
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: 1.4
Hardware: All
OS: Linux
low
high
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks: jon24-apache jon-sprint12-bugs jon241-bugs
TreeView+ depends on / blocked
 
Reported: 2010-07-29 03:09 UTC by Corey Welton
Modified: 2010-08-26 13:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-26 13:55:32 UTC
Embargoed:


Attachments (Terms of Use)
screeshot #1 of augeas fields that are not populated by default upon upgrade (24.71 KB, image/png)
2010-07-29 03:11 UTC, Corey Welton
no flags Details
screenshot #2 of augeas fields that are not populated by default upon upgrade (31.96 KB, image/png)
2010-07-29 03:12 UTC, Corey Welton
no flags Details

Description Corey Welton 2010-07-29 03:09:35 UTC
Description of problem:
Not sure of the exact cause here but I think I know.  But I think thatif a user has a misconfigured/"red" (inventoried but not monitored) httpd instance in 2.3.1 and upgrades to 2.4, the server remains red.  But when user goes into connection properties, there are a bunch of blank fields that need to be populated before the server can (presumably) go green.  It is not readily apparent what the default values should be here.

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


How reproducible:


Steps to Reproduce:
1. Assure you have httpd installed on a system.  Register and inventory the system.  Note that I /think/ you don't want Apache configured to where it has gone green.
2. Shutdown server; upgrade to 2.4
3. Login to JON; note your Apache instance is (still?) red
4. Apache Httpd server > $instance > Inventory > Connection
5. View fields in the Connection props page.

  
Actual results:
Note the # of fields with red asterisks that are otherwise sans content.  User probably shouldn't be expected to know these values already?


Expected results:
Populate these with default values...

Additional info:
I am not yet sure if actually populating these correctly brings the server back up.

Comment 1 Corey Welton 2010-07-29 03:11:38 UTC
Created attachment 435181 [details]
screeshot #1 of augeas fields that are not populated by default upon upgrade

Comment 2 Corey Welton 2010-07-29 03:12:07 UTC
Created attachment 435182 [details]
screenshot #2 of augeas fields that are not populated by default upon upgrade

Comment 3 Corey Welton 2010-07-29 03:25:02 UTC
Actually screenshot #2 is not augeas but vhosts.

The good news is that uninventorying the resource and reinventorying it seems to make everything all better.

The bad news is that populating those fields appropriately ("Httpd", "/etc/httpd/conf/httpd.conf", "(*) Each Virtual Host in a standalone file", "conf.d/*.conf" would be the most likely candidates, respectively) doesn't seem to resolve the issue.   I got a huge stack trace and may have even choked the agent though it might have been something else.

Comment 4 Filip Drabek 2010-07-29 09:24:21 UTC
I think that this problem is related to https://bugzilla.redhat.com/show_bug.cgi?id=573034

Comment 5 Sunil Kondkar 2010-07-29 13:36:04 UTC
Tested with the steps and the bug was reproducible. The fields in the
Connection props page as mentioned in the screenshots are not populated after
upgrade. 

I haven't filled the 'URL' field in 'Apache Httpd server > $instance >
Inventory > Connection' before upgrade to 2.4. So the apache resource was red.
Apache was still red after upgrade to 2.4. 

However, when i entered the URL(http://localhost:80) in 'Apache Httpd server >
$instance > Inventory > Connection' after upgrade, the apache resource turned
into green and available.

Comment 6 Filip Drabek 2010-08-26 13:55:32 UTC

*** This bug has been marked as a duplicate of bug 573034 ***


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