Bug 769948 - [apache] "phantom" Main virtual host appears in the inventory if the apache server resource does not have the URL set in the configuration properties
[apache] "phantom" Main virtual host appears in the inventory if the apache s...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
3.0.1
Unspecified Unspecified
urgent Severity medium (vote)
: ---
: JON 2.4.2
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-22 14:54 EST by Charles Crouch
Modified: 2015-02-01 18:27 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 690435
Environment:
Last Closed: 2012-02-07 14:25:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2011-12-22 14:54:12 EST
+++ This bug was initially created as a clone of Bug #690435 +++

Description of problem:

$SUMMARY

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

How reproducible:
always

Steps to Reproduce:
1. discover and inventory an apache instance
2. unset the URL in the connection properties of the apache server resource
3. wait for or force the availability check
  
Actual results:
a second virtual host called "Main" (with availability down) appears in the inventory with the resource key "MainServer".

Expected results:
no new vhosts appear

Additional info:

--- Additional comment from bkramer@redhat.com on 2011-03-30 06:07:38 EDT ---

An addition to the "Steps to reproduce" in the original comment #1:

It seems that the invalid additional vhosts is created when specifying:

Listen 0.0.0.0:80 

rather then 

Listen 80 (this is a default setting in the httpd.conf).

To reproduce the issue:

1) change httpd.conf file to specify: Listen 0.0.0.0:80
2) start Apache instance;
3) Import discovered Apache instance into JON inventory;
4) Confirm that Apache server is up and running (in JON) and that Main vhosts is up and running;
5) For selected Apache instance go to Inventory -> Connection, unset URL property and save the change;
6) Request "avail" from the JON Agent command line or from Operations -> "Execute Availability Scan" for selected RHQ Agent;
7) Refresh the JON UI and confirm that Apache Server is still up and running but with two Main vhosts, where one is green and the other one is red.

If we use default Listen 80 setting then Apache is up and running with one vhosts and it stays like that even when URL property is removed.

--- Additional comment from mazz@redhat.com on 2011-04-01 11:36:35 EDT ---

see if we can fix or at minimum document the workarounds somewhere

--- Additional comment from ccrouch@redhat.com on 2011-05-25 10:09:41 EDT ---

We need to make sure this doesn't happen in master and doesn't happen on upgrades from 2.3/2.4/2.4.1 to JON3 for example

--- Additional comment from lkrejci@redhat.com on 2011-05-26 06:20:23 EDT ---

This doesn't happen in master, because RHQ4 always uses the MainServer resource key for the Main vhost, unlike the RHQ3 version which tried to assign an "URL-like" resource key (and failed in the scenario described in this BZ) for backwards compatibility reasons.

Currently in master, the upgrade will fail with an error message saying that 2 resources would end up with a same resource key after upgrade. This is resolvable by removing one of the Main vhosts from the inventory and restarting the plugin container (which will re-run the upgrade which will succeed).

I am not sure we can always assume that the Main vhost with the resource key "MainServer" discovered in the RHQ3 codebase is the one to remove. Even if it was (which would require careful examination of the server discovery code), the only thing we could do would be to specifically fail the upgrade for this particular vhost and include an error message that would suggest the user that they can uninventory this vhost and restart the plugin container to resolve that situation. The upgrade framework has no ability to automatically uninventory resources.

--- Additional comment from loleary@redhat.com on 2011-06-07 17:28:24 EDT ---

(In reply to comment #4)
> ...
> I am not sure we can always assume that the Main vhost with the resource key
> "MainServer" discovered in the RHQ3 codebase is the one to remove. Even if it
> was (which would require careful examination of the server discovery code), the
> only thing we could do would be to specifically fail the upgrade for this
> particular vhost and include an error message that would suggest the user that
> they can uninventory this vhost and restart the plugin container to resolve
> that situation. The upgrade framework has no ability to automatically
> uninventory resources.

Correct. It would appear that the MainServer virtual host would be valid in the event the Apache Web Server URL is empty. In other words:

If MainServerURL == NULL
  Virtual Host Resource Key = "MainServer" is valid and the one in use
If MainServerURL != NULL
  Virtual Host Resource Key = "MainServer" is invalid and should be removed

The problem with this logic is that in the case the MainServerURL is NULL, there still may be one or more Main Virtual Host resources that contain a URL for their resource key but if we don't know which one is actually for the main server and which one is for a real virtual host, which one(s) should get removed?

Because of this risk, it would seem that an upgrade fail would be a safer result to allow the user to determine which is the valid one and which is the invalid one... however, this will also complicate the upgrade. Especially in situations where there are many Apache Web Server resource's on each agent meaning that the user would need to go through each, one by one, and fix the problem. Thus, requiring a lot of time and patience.

--- Additional comment from ccrouch@redhat.com on 2011-06-08 15:47:34 EDT ---

Another Apache issue. Assigning to Lukas so he can closes the dupes

--- Additional comment from lkrejci@redhat.com on 2011-06-13 17:01:01 EDT ---

commit 7fbb6446e0cdaae660d80ac76ff222ec786746f8
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Mon Jun 13 17:22:54 2011 +0200

    BZ 690435 - Changing the main server vhost to always use the SNMP-like resource key to prevent the appearance of duplicates when parent server's URL property changes.

--- Additional comment from lkrejci@redhat.com on 2011-06-13 17:07:24 EDT ---

*** Bug 693666 has been marked as a duplicate of this bug. ***

--- Additional comment from skondkar@redhat.com on 2011-06-20 07:58:16 EDT ---

Verified on build 149 (Version: 4.1.0-SNAPSHOT Build Number: 04f721e)

Changed the httpd.conf file with Listen 0.0.0.0:80.
Started Apache instance; and imported discovered Apache instance.
Confirmed that Apache server is up and running and that the Main vhost is up and running.
Navigated to Inventory -> Connection Settings and unset and saved URL
property.
Requested "avail" from the Agent prompt command.
Verified that Apache Server is down and displays only one Main vhost.

Marking as verified.
Comment 1 Sunil Kondkar 2011-12-29 07:05:39 EST
Verified on version: 2.4.2.GA build number: 3fd0075:1afdc60

Changed the httpd.conf file with Listen 0.0.0.0:80.
Started Apache instance; and imported discovered Apache instance.
Confirmed that Apache server is up and running and that the Main vhost is up
and running.
Navigated to Inventory -> Connection Settings and unset and saved URL
property.
Requested "avail" from the Agent prompt command.
Verified that Apache Server is down and displays only one Main vhost.
Comment 2 Mike Foley 2012-02-07 14:25:27 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

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