On 11/26/2014 02:36 PM, Amit Anand wrote:
Same error - also tried with 127.0.0.1. Even crazier I removed all
keystone nova (user, service, etc) and dropped the nova DB and recreated
that, then recreated keystone nova with a new different password,
updated nova.conf with new password and still get the same error (notice
below now nova has the different password):
Permissions for a user are not affected by the removal of a database.
You can even add permissions for a user to operate on a database that
doesn't exist:
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
4 rows in set (0.03 sec)
mysql> GRANT ALL ON foo.* TO root@localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON test.* TO root@localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> USE mysql
Database changed
mysql> SELECT * FROM db WHERE User = 'root' AND Db = 'foo'\G
*************************** 1. row ***************************
Host: localhost
Db: foo
User: root
Select_priv: Y
Insert_priv: Y
Update_priv: Y
Delete_priv: Y
Create_priv: Y
Drop_priv: Y
Grant_priv: N
References_priv: Y
Index_priv: Y
Alter_priv: Y
Create_tmp_table_priv: Y
Lock_tables_priv: Y
Create_view_priv: Y
Show_view_priv: Y
Create_routine_priv: Y
Alter_routine_priv: Y
Execute_priv: Y
Event_priv: Y
Trigger_priv: Y
1 row in set (0.00 sec)
Go figure :)
If you manually specify the host on the command line, do you still get
in to the MySQL server?
i.e., if you do this on the command line, does it work?
mysql -unova -hlocalhost -p -Dnova
Best,
-jay
MariaDB [mysql]> SELECT user,password,host FROM user;
+----------+-------------------------------------------+-----------+
| user | password | host |
+----------+-------------------------------------------+-----------+
| root | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |
| root | *7088873CEA983CB57491834389F9BB9369B9D756 | 127.0.0.1 |
| root | *7088873CEA983CB57491834389F9BB9369B9D756 | ::1 |
| keystone | *7088873CEA983CB57491834389F9BB9369B9D756 | % |
| keystone | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |
| glance | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |
| glance | *7088873CEA983CB57491834389F9BB9369B9D756 | % |
| nova | *3DA97D7423D54524806BFF6A19D94F78EEF97338 | localhost |
| nova | *3DA97D7423D54524806BFF6A19D94F78EEF97338 | % |
| root | *7088873CEA983CB57491834389F9BB9369B9D756 | % |
+----------+-------------------------------------------+-----------+
10 rows in set (0.00 sec)
On Wed, Nov 26, 2014 at 2:26 PM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:
On 11/26/2014 02:21 PM, Amit Anand wrote:
Hi Jay - I believe so below is the part that is in the nova.conf
# The SQLAlchemy connection string used to connect to the
# bare-metal database (string value)
connection=mysql://nova:__PASSWORD@controller/nova
The PASSWORD is exactly the same what I have in the conf file
and what I
have in the nova.conf
Im doing this manually via the Juno instruction guide for CentOs 7.
try:
connection=mysql://nova:__PASSWORD@localhost/nova
Best,
-jay
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack