Bug 1237110

Summary: Cannot change server's zone from 'default'
Product: Red Hat CloudForms Management Engine Reporter: Ramesh A <rananda>
Component: ApplianceAssignee: Tim Wade <twade>
Status: CLOSED ERRATA QA Contact: Ramesh A <rananda>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.4.0CC: abellott, cpelland, fdewaley, gtanzill, jhardy, jocarter, mfeifer, obarenbo, twade
Target Milestone: GAKeywords: ZStream
Target Release: 5.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.5.0.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1246245 (view as bug list) Environment:
Last Closed: 2015-12-08 13:20:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1246245    
Attachments:
Description Flags
before.png
none
after.png none

Description Ramesh A 2015-06-30 11:52:21 UTC 
Description of problem:
Attempting to change the zone of the first server deployed fails despite the UI indicating a successful change. 

NOTE: The zone of secondary servers spun up after the first can be changed.

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


How reproducible:


Steps to Reproduce:
1. Log in as an admin user and select Configure -> Configuration
2. Create a zone if one hasn't already been configured.
3. Select the first server deployed (in this case, Server: EVM [1] (current)) and change its zone from "default" to another zone.
4. Save.

Actual results:
Unable to change.  Refer the additional information section for more details.


Expected results:
Should be able to change it

Additional info:

Before adding the new zone:
===========================
[root@server config]# grep -i zone vmdb.yml.db
  timezone: UTC
  zone: default

vmdb_production=#  select id, name from zones;
 id |  name   
----+---------
  1 | default
(1 row)

vmdb_production=# select id, name, zone_id from miq_servers;
 id | name | zone_id 
----+------+---------
  1 | EVM  |       1
(1 row)


After adding the new zone:
=========================

[root@server config]# grep -i zone vmdb.yml.db
  timezone: UTC
  zone: ramesh-test-zone


vmdb_production=#  select id, name from zones;
 id |    name     
----+-------------
  1 | default
  2 | ramesh-test-zone
(2 rows)


vmdb_production=# select id, name, zone_id from miq_servers;
 id | name | zone_id 
----+------+---------
  1 | EVM  |       1
(1 row)
Comment 1 Ramesh A 2015-06-30 11:53:23 UTC 
Build info -  5.4.0.5.20150605150206_7daa1a8
Comment 2 Ramesh A 2015-06-30 11:53:36 UTC 
Github link - https://github.com/ManageIQ/manageiq/issues/2561
Comment 5 CFME Bot 2015-07-08 21:34:14 UTC 
New commit detected on manageiq/master:
https://github.com/ManageIQ/manageiq/commit/bc9beab9b0f5968c8d33d6a8ae0ae1b0c400d34a

commit bc9beab9b0f5968c8d33d6a8ae0ae1b0c400d34a
Author:     Tim Wade <hello>
AuthorDate: Thu Jul 2 11:15:33 2015 -0700
Commit:     Tim Wade <hello>
CommitDate: Wed Jul 8 08:38:04 2015 -0700

    Save server's zone when changing basic information/zone.
    
    Addresses an issue when changing the zone in configure -> configuration
    -> zones -> <zone> -> <server>. Before, updating the zone reports that
    it was successful, but does not change the zone of the server.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1237110

 app/controllers/ops_controller/settings/common.rb |  8 ++++-
 spec/controllers/ops_controller_spec.rb           | 38 +++++++++++++++++++++++
 2 files changed, 45 insertions(+), 1 deletion(-)
Comment 6 Dan Clarizio 2015-07-23 19:12:07 UTC 
*** Bug 1246101 has been marked as a duplicate of this bug. ***
Comment 8 Harpreet Kataria 2015-07-30 15:40:14 UTC 
*** Bug 1237320 has been marked as a duplicate of this bug. ***
Comment 9 Ramesh A 2015-09-16 06:38:48 UTC 
Good to go.  Verified and working fine in master.20150916012703_4e04cf0


Before adding the new zone:
===========================
[root@server config]# grep -i zone vmdb.yml.db
  timezone: UTC
  zone: default

vmdb_production=# select id, name from zones;
 id |  name   
----+---------
  1 | default
(1 row)

vmdb_production=# select id, name, zone_id from miq_servers;
 id | name | zone_id 
----+------+---------
  1 | EVM  |       1
(1 row)



After adding the new zone:
==========================
[root@server config]# grep -i zone vmdb.yml.db
  timezone: UTC
  zone: ramesh-test-zone


vmdb_production=# select id, name from zones;
 id |       name       
----+------------------
  1 | default
  2 | ramesh-test-zone
(2 rows)

vmdb_production=# select id, name, zone_id from miq_servers;
 id | name | zone_id 
----+------+---------
  1 | EVM  |       2
(1 row)
Comment 10 Felix Dewaleyne 2015-09-16 09:50:08 UTC 
don't forget to go to the interface - the zone were correctly changed in the database but the configure > configuration page did not reflect the zone change.
Comment 11 Ramesh A 2015-09-16 14:54:04 UTC 
Hi Felix,

I am able to see the changes getting reflected as per the changes made.  Please find the screenshot's "before.png" and "after.png" for more details.  Let me know if you are pointing something else.

Thanks,
Ramesh
Comment 12 Ramesh A 2015-09-16 14:54:36 UTC 
Created attachment 1074069 [details]
before.png
Comment 13 Ramesh A 2015-09-16 14:55:06 UTC 
Created attachment 1074071 [details]
after.png
Comment 14 Felix Dewaleyne 2015-09-16 15:05:10 UTC 
no, that's pretty much it. The fact is, the database was being updated correctly previously, but not the interface, and the screenshots provided show what I would call the expected behaviour
Comment 15 Tim Wade 2015-09-17 16:44:51 UTC 
> Description of problem:
> Attempting to change the zone of the first server deployed fails despite the UI indicating a successful change.

Are we saying that the UI used to indicate a successful change, but no longer does? Could this be a separate issue?
Comment 17 Ramesh A 2015-09-24 11:36:39 UTC 
https://bugzilla.redhat.com/show_bug.cgi?id=1237110
Comment 22 errata-xmlrpc 2015-12-08 13:20:13 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2015:2551