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

Reply via email to