* create or upgrade the database as necessary, just as with the traditional single-server install, that runs when the first new/upgraded server starts up * a different installer page that runs when the 2nd, 3rd, 4th, etc servers are started ** this page needs to handle adding this instance to the HA database tables (server group membership will happen naturally during startup as a result of logic from RHQ-673)
r1183 : Updates the installer for HighAvail (HA). In effect a server install is now registered inside the configured db. Each server installing with a different name is considered a server in the "cloud" for HA purposes. You can add new servers to the cloud or choose to re-install/upgrade a previously registered server. The big difference is that now there are 4 required fields to be supplied, and optionally a 5th, when doing a server install. The good news is that these all have default values such that performing an install does not have to be more complex that it was previously. Server Name (defaults to resolved localhost name) Server Endpoint Address (defaults to resolved localhost address ) Server Endpoint Port (defaults to 7080, same as HTTP) Server Endpoint Secure Port (defaults to 7443, same as HTTPS) Server Affinity Group Name (only shown with advanced properties, defaults to 'none') QA Scenarios: 1) New or Overwritten DB - In either of these cases there will be no registered servers in the db. The user will be presented with the new fields, pre-filled with defaults, and can modify them only if needed. 2) Upgrade from 1.0.1 to 1.1 (Keep DB) - In this scenario there also will be no registered servers in the db. The user will be presented with the new fields, pre-filled with defaults, and can modify them only if needed. 3) Keep DB and existing servers are registered. - In this scenario there may be 1 or more servers installed against the db. In effect, a 1.1 server cloud exists. Even a single server can be thought of as a 1-server cloud with respect to HA. The user will be presented with a dropdown list of existing servers, as well as the typical text boxes for manual input. The user can: a) select from the list. The user can The stored settings will be used to pre-fill the fields. This is the option to take if performing an upgrade/re-install of an existing server. The non-name fields can be updated during the install, if necessary. b) ignore the list and add a new server to the cloud. This is the option to take only is you are truly increasing the size of your HA Cloud. Note that after installation HA information will be managed via the GUI in the HA Admin Console. So, for example, if you have an IP change for a server, or need to re-organize Affinity Group settings, it would be done there. Additionally, if you want to remove a server from the cloud it would be done via the HA console. The installer only gets you up and running.
r1224 - More work on the installer to incorporate feedback from ghinkle and jmarques. now uses applies htto and https properties to server-side endpoint (db persisted endpoint info). look and feel changes as well as more on-screen guidance. fixed problem when default server name is already registered. removed jboss cluster properties (although, everything remains, just commented as necessary) and deactivated cluster-service deploy.
rev1225 - make sure "undeploy-cluster-service" target always run, regardless of options passed in to the container build; do not fail on error if the cluster-service.xml file doesn't exist, instead assume that it was moved on a previous build;
Completed scenarios 1,2, and 3. Reinstalled the first node using its registered name and verified it came back up correctly and there were no extra nodes. Will continue to test the HA installer as other components of HA need to be tested. rev1250.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-677