| Summary: | [DOC] Unable to use db reset option if created dedicated db | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | luke couzens <lcouzens> |
| Component: | Documentation | Assignee: | Red Hat CloudForms Documentation <cloudforms-docs> |
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat CloudForms Documentation <cloudforms-docs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.7.0 | CC: | abellott, adahms, bthurber, dajohnso, gtanzill, hhudgeon, jhardy, lcouzens, linux1, ncarboni, obarenbo, yrudman |
| Target Milestone: | GA | Keywords: | Regression, Reopened |
| Target Release: | 5.9.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | black | ||
| Fixed In Version: | Doc Type: | Release Note | |
| Doc Text: |
If you configure a Red Hat CloudForms appliance to act as a dedicated database instance when you configure the database, you can enable the EVM server and user interface on that appliance via the following procedure -
If you have already configured a region on the appliance and other appliances connect to that region, use the 'Join Region in External Database' option to enable the EVM server. Enter 'localhost' as the database host name.
If you have not already configured a region on the appliance, use the 'Create Region in External Database' option to enable the EVM server. Enter 'localhost' as the database host name.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-08 23:41:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | CFME Core | Target Upstream Version: | |
|
Description
luke couzens
2016-11-07 13:00:54 UTC
We currently have the exact same behavior, any news on this ? Gregg -- is this really ON_DEV? In other words, is someone actively working on a PR? Different menu should be selected when adding EVM server to stand-alone DB installation. 'Reset Configured Database' should be selected when resetting local DB which has region set-up already. There could be 2 configurations while enabling EVM on dedicated DB server: - Dedicated DB server already has region set-up and there are other EVM servers pointing to it. Use 'Join Region in External Database' option to enable EVM server (enter 'localhost' as database hostname). - Dedicated DB server does not have region set-up and there are no other EVM servers using it (as described in this BZ). Use 'Create Region in External Database' option to enable EVM server (enter 'localhost' as database hostname). Correction in previous description: should read SFME server instead of EVM. Luke, could you confirm that 'Create Region in External Database' allows to reset appliance configuration. Hi Yuri, I assume you meant CFME not SFME? As for the other bit I have created a dedicated db and created said region using 'Create Region in External Database'. I then stop evm and run a reset on the cfme appliance it allows me to reset and change the region. I can confirm that this works but this is not actually my original issue. What I was trying to do was reset a dedicated db configuration, i.e revert a dedicated db setup and make it a local cfme appliance with a region instead, without the need of killing the current appliance and starting a fresh, or being drastic and cleaning out the postgres dir. Maybe this is not possible and needs to be RFE? > What I was trying to do was reset a dedicated db configuration, i.e revert a
> dedicated db setup and make it a local cfme appliance with a region instead,
> without the need of killing the current appliance and starting a fresh, or
> being drastic and cleaning out the postgres dir.
>
> Maybe this is not possible and needs to be RFE?
First, I think Yuri's instructions would accomplish what you're describing here, but maybe some more words about how database servers, regions, and servers interact would help.
The "typical" internal database configuration configures a new postgres cluster (data directory), the database (vmdb_production), and a user with a password; it also sets up the local server to point to that new database (by configuring database.yml). It then migrates up the database to create the schema and seeds some initial data (this is what we call "creating a region").
The standalone database configuration sets up the postgres server, database, and user, but does nothing related to the application (doesn't create the schema or write database.yml).
Now, when a user wants to connect to an external database, all that needs to be done is to write database.yml, either create the region ("Create region in external database") or not ("Join region in external database") and start the server.
So you can have a server which configured the database as standalone then run through whichever external option (using "localhost" for the database hostname) makes sense for the situation you are in to configure the local app to the local database.
I think the issue is more with naming than anything else, but you can't really put options like "Configure database.yml" and "Configure PostgreSQL cluster" in front of users and expect them to know what that means.
Thanks for that Nick, I totally understand what Yuri was saying now. It does in fact work exactly as he described, you can just run create on the dedicated db appliance and run it against localhost to configure it. After this you can also use the reset db option like normal. I guess this is not really a bug in this case then? Maybe just an addition to some documentation or something? Thanks again guys! Yeah, I think documenting how these options work would help, but I think I would rather make the wording better in the console itself. Unfortunately, I can't come up with anything better than what we already have ... Thank you for raising this bug. We have evaluated this request, and while we recognize that it is a valid request for the documentation, we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Andrew Dahms. |