Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot change server's zone from 'default' #2561

Closed
stacybrock opened this issue Apr 8, 2015 · 4 comments
Closed

Cannot change server's zone from 'default' #2561

stacybrock opened this issue Apr 8, 2015 · 4 comments

Comments

@stacybrock
Copy link

Issue: On a brand-new deployment of the Botvinnik-RC1 vsphere OVA, 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.

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. (In this example, the zone is "OSU_SIG".)
  3. Select the first server deployed (in this case, miq-bot-master) and change its zone from "default" to another zone.
  4. Save.

screen shot 2015-04-08 at 2 19 29 pm
(Note that the zone has not actually changed from "default" despite the value being correct in the zone dropdown.)

evm.log indicates success:

[----] I, [2015-04-08T14:09:43.038934 #10732:3b3e90]  INFO -- : MIQ(Configuration.create_or_update) Updated server configuration: id: [1], typ: [vmdb], miq_server_id: [1]
[----] I, [2015-04-08T14:09:43.061624 #10732:3b3e90]  INFO -- : MIQ(Config.save) Saved Config [vmdb] from database in file: [/var/www/miq/vmdb/config/vmdb.yml.db]
[----] I, [2015-04-08T14:09:43.080460 #10732:3b3e90]  INFO -- : MIQ(MiqQueue.put)        Message id: [1082],  id: [], Zone: [default], Role: [], Server: [3d466486-de1d-11e4-9547-005056a4145a], I
dent: [generic], Target id: [], Instance id: [1], Task id: [], Command: [MiqServer.ntp_reload], Timeout: [600], Priority: [20], State: [ready], Deliver On: [], Data: [], Args: [{:server=>["0.poo
l.ntp.org", "1.pool.ntp.org", "2.pool.ntp.org"]}]
[----] I, [2015-04-08T14:09:43.086792 #10732:3b3e90]  INFO -- : <AuditSuccess> MIQ(Common.settings_update_save) userid: [admin] - miq-bot-master [1] in zone default VMDB config updated (zone:[de
fault] to [OSU_SIG])

Config file has been changed:

[root@miq-bot-master config]# grep -i zone vmdb.yml.db
  timezone: Pacific Time (US & Canada)
  zone: OSU_SIG

But lo, the database has not:

bot_vmdb_production=# select id, name from zones;
 id |  name
----+---------
  1 | default
  3 | OSU_SIG
(2 rows)

bot_vmdb_production=# select id, name, zone_id from miq_servers;
 id |      name       | zone_id
----+-----------------+---------
  1 | miq-bot-master  |       1
  2 | miq-bot-caputil |       3
(2 rows)
Session Information Value
Server Name miq-bot-master
Version botvinnik-1-rc1.20150408140116_7d08701
User Name Administrator
User Role EvmRole-super_administrator
Browser Firefox
Browser Version 36
Browser OS Mac
@Fryguy Fryguy added the bug label Apr 20, 2015
@Fryguy
Copy link
Member

Fryguy commented Apr 20, 2015

@dajohnso Can you verify this?

@rananda
Copy link

rananda commented Jun 30, 2015

@Fryguy , I was able to reproduce it locally. Please find the details

Build - master.20150629224614_5c763a8

Before:

[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:

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

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

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

@rananda
Copy link

rananda commented Jun 30, 2015

@gtanzillo
Copy link
Member

Closing since this issue should be fixed in the Capablanca release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants