Bug 690435

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.

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

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

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.

(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.

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

commit 7fbb6446e0cdaae660d80ac76ff222ec786746f8
Author: Lukas Krejci <lkrejci>
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.

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

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.

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.