[Openstack] Nova DB sync Operational error

Narayanan, Krishnaprasad narayana at uni-mainz.de
Wed Nov 26 22:20:49 UTC 2014


Hi Amit,

Can you verify the GRANTS allowed on the nova database? By GRANTS, I mean the privileges / permissions for the nova database.

Regards,
Krishnaprasad
From: Amit Anand [mailto:aanand at viimed.com]
Sent: Mittwoch, 26. November 2014 22:56
To: Jay Pipes
Cc: openstack at lists.openstack.org
Subject: Re: [Openstack] Nova DB sync Operational error

Well created a new controller on a whole new machine and get all the way up until compute and get same error again. I have to think it something with my nova.conf but I cant figure it out. Ive pasted here so if anyone can take a look and see maybe what Im doing incorrect I would appreciate it...

http://paste.openstack.org/show/139079/




On Wed, Nov 26, 2014 at 4:09 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:
Im going to try building a new controller on a whole new nuc see if I get the same I will keep yall abreast if it works or not. In any case thank you very much for all your help!!!

On Wed, Nov 26, 2014 at 3:56 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:

Password is viimed1



On Wed, Nov 26, 2014 at 3:55 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:
George

Thanks. Yeah there no other nova.conf I went as far as to do a find in case I put somewhere nothing turned up except the proper one. I did have a nova.conf.orig (I always make a backup so i can always start over) and was hoping maybe you hit the nail on the head so I moved that out to my  /home/amit dir but alas that failed as well  :-(

Permissions I made rwrwrw still same.





On Wed, Nov 26, 2014 at 3:42 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:
Geo

Error logs are here:

http://paste.openstack.org/show/139035/

When I run your command with password nova it fails - when I run it with the real password it works fine

[root at controller ~]# mysql -u nova -p -h controller nova
Enter password:
I entered nova here
ERROR 1045 (28000): Access denied for user 'nova'@'controller' (using password: YES)


[root at controller ~]# mysql -u nova -p -h controller nova
Enter password:
I entered real password here
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 5.5.40-MariaDB MariaDB Server

Copyright (c) 2000, 2014, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [nova]> quit
Bye





On Wed, Nov 26, 2014 at 3:36 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:
Jay,

So this is the command that u sent, works just fine connect to Nova DB:

[root at controller nova]# mysql -unova -hlocalhost -p -Dnova
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 5.5.40-MariaDB MariaDB Server

Copyright (c) 2000, 2014, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [nova]>


I also changed in nvoa.conf connection=mysql://nova:__PASSWORD@localhost/nova (I tried with both a space and a _ as I was not sure exactly what you meant - still same error) :-(

I also took a look at a command you ran and I tried it, would this be correct output (notice I didnt specify a DB in command)?

MariaDB [mysql]> SELECT * FROM db WHERE User = 'root'\G
*************************** 1. row ***************************
                 Host: %
                   Db: nova
                 User: root
          Select_priv: Y
          Insert_priv: Y
          Update_priv: Y
          Delete_priv: Y
          Create_priv: Y
            Drop_priv: Y
           Grant_priv: Y
      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.01 sec)

Also this is the output for user Nova:

MariaDB [mysql]> SELECT * FROM db WHERE User = 'nova'\G;
*************************** 1. row ***************************
                 Host: localhost
                   Db: nova
                 User: nova
          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
*************************** 2. row ***************************
                 Host: %
                   Db: nova
                 User: nova
          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
2 rows in set (0.00 sec)


On Wed, Nov 26, 2014 at 3:12 PM, Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:
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 at localhost;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL ON test.* TO root at 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 <jaypipes at gmail.com<mailto:jaypipes at gmail.com>
<mailto:jaypipes at gmail.com<mailto:jaypipes at 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







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141126/0162cc3a/attachment.html>


More information about the Openstack mailing list