I couldn't find anything really similar. Anyway, the migration wen well. We dropped the database, run nova-manage db sync, nova-manage network create (we also changed the internal IP addressing scheme) and we inserted the entries we wanted to save.
Now everything work smoothly: creation/deletion of instances etc. .a. On Thu, Nov 7, 2013 at 9:22 AM, Razique Mahroua <[email protected]> wrote: > interesting…. > > I don’t really understand that case. Have you checked on launchpad for > similar bugs? > > > -- > Razique > > On 7 Nov 2013 at 00:22:28, Antonio Messina ([email protected]) > wrote: > > On Thu, Nov 7, 2013 at 1:50 AM, Razique Mahroua > <[email protected]> wrote: >> Are others CLI operations fine? such as keystone user-list, nova reboot >> etc…? > > Yes, nova list, nova reboot, keystone, glance, they all work fine > except when I have to create or terminate an instance. > > .a. > >>> On 6 Nov 2013 at 06:28:16, Antonio Messina ([email protected]) >>> wrote: >>> >>> On Wed, Nov 6, 2013 at 3:06 PM, Razique Mahroua >>> <[email protected]> wrote: >>>> I can do some consulting if you want :p >>> >>> This may be interesting, but totally off topic :) >>> >>>> Which mail are you referring to? >>> >>> This one: >>> http://lists.openstack.org/pipermail/openstack/2013-November/002623.html >>> subject: "Instances fail during/after networking" >>> >>>> and what do you mean by “crazy”? Performance-wise or did you have some >>>> bugs >>>> due to your inconsistent database? >>> >>> nova-network is spinning at 80-90% of cpu for minutes, giving IP >>> addresses only after a few *minutes*, so that the creation of the VM >>> goes in timeout and thus is failing. >>> Similarly when deleting a VM, it takes ages and sometimes I have to >>> terminate them twice in order to have them killed. >>> >>> .a. >>> >>> >>>> >>>> -- >>>> Razique >>>> >>>> On 6 Nov 2013 at 06:06:47, Antonio Messina ([email protected]) >>>> wrote: >>>> >>>> On Wed, Nov 6, 2013 at 12:46 PM, Razique Mahroua >>>> <[email protected]> wrote: >>>>> I’d say it’s risky since it’s possible that you end up with >>>>> inconsistent >>>>> states, especially with the security_groups and keypairs tables. >>>>> >>>>> You should probably dump the whole database and restore it if needed >>>> >>>> I cannot. >>>> The reason why I need to do it is because the current database is >>>> already in a state which is driving nova-network crazy. >>>> >>>> I have sent an email a few days ago about the problem we are having >>>> with our installation. After some more checking, it seems that the >>>> problem is caused by the *data* currently stored in the database; we >>>> tried with an empty one and everything was working smoothly: instances >>>> are started within one minute and deleted as needed, while going back >>>> to the original database brings back the issue. >>>> >>>> So, we guess it's something on the database, but we don't have either >>>> the time nor the competence nor the need to further debug the issue, >>>> since we are planning to move Havana soon and we have to keep the >>>> cloud up&running ASAP. >>>> >>>> Therefore we decided to clean up the database and remove more or less >>>> everything, but as I said, we would like to keep the information >>>> mentioned before. >>>> >>>> .a. >>>> >>>>> >>>>> >>>>> Razique >>>>> >>>>> -- >>>>> Razique >>>>> >>>>> On 6 Nov 2013 at 03:46:02, Antonio Messina >>>>> ([email protected]) >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We need to backup and then recover some information from the nova >>>>> database, specifically: >>>>> >>>>> * flavors >>>>> * quotas >>>>> * keypairs >>>>> * security groups >>>>> >>>>> I would like to know which tables I am supposed to back up and >>>>> recover, I guess the following: >>>>> >>>>> * quotas >>>>> * security_groups >>>>> * security_group_rules >>>>> * instance_types >>>>> >>>>> are enough? Can I just dump them with mysqldump and recover them with >>>>> mysql < backupfile? >>>>> >>>>> .a. >>>>> >>>>> -- br/>antonio.s.messina@@gmail.com >>>>> [email protected] +41 (0)44 635 42 22 >>>>> GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ >>>>> University of Zurich >>>>> Winterthurerstrasse 190 >>>>> CH-8057 Zurich Switzerland >>>>> >>>>> _______________________________________________ >>>>> Mailing list: >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>>>> Post to : [email protected] >>>>> Unsubscribe : >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>>> >>>> >>>> >>>> -- br/>antonio.s.messina@@gmail.com >>>> [email protected] +41 (0)44 635 42 22 >>>> GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ >>>> University of Zurich >>>> Winterthurerstrasse 190 >>>> CH-8057 Zurich Switzerland >>> >>> >>> >>> -- >>> [email protected] >>> [email protected] +41 (0)44 635 42 22 >>> GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ >>> University of Zurich >>> Winterthurerstrasse 190 >>> CH-8057 Zurich Switzerland >> >> >> >> -- >> [email protected] >> [email protected] +41 (0)44 635 42 22 >> GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ >> University of Zurich >> Winterthurerstrasse 190 >> CH-8057 Zurich Switzerland > > > > -- br/>antonio.s.messina@@gmail.com > [email protected] +41 (0)44 635 42 22 > GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ > University of Zurich > Winterthurerstrasse 190 > CH-8057 Zurich Switzerland -- [email protected] [email protected] +41 (0)44 635 42 22 GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ University of Zurich Winterthurerstrasse 190 CH-8057 Zurich Switzerland _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
