[Openstack] Nova DB sync Operational error

Amit Anand aanand at viimed.com
Wed Nov 26 22:20:21 UTC 2014


Ok well figured it out!!!

I guess its either me or the documentation. I basically got rid of the
original nova.conf (that comes with the distro) and then I just made a new
nova.conf with only the changes that are listed in the documentation (ie I
created [database] [DEFAULT] etc sections listed there only) and then ran
DB sync an viola! It seems to work. Crazy

Now Im worried (even tho everything seems to have worked) that the conf
files for glance and keystone maybe incorrect because  just edited the
original conf files that came with the distro. Would anyone have any idea?

Also do you think this would be valuable to post on Ask Openstack and/or
report it as a bug??

My new nova.conf:  http://paste.openstack.org/show/139105/

Thanks everyone!!!

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

> 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> 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> wrote:
>>
>>>
>>> Password is viimed1
>>>
>>>
>>>
>>> On Wed, Nov 26, 2014 at 3:55 PM, Amit Anand <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> 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> 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:__PASS
>>>>>> WORD at 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>
>>>>>> 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>> 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/464a5791/attachment.html>


More information about the Openstack mailing list