Open Stack

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
<razique.mahroua at gmail.com> 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 (antonio.s.messina at gmail.com)
> wrote:
>
> On Thu, Nov 7, 2013 at 1:50 AM, Razique Mahroua
> <razique.mahroua at gmail.com> 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 (antonio.s.messina at gmail.com)
>>> wrote:
>>>
>>> On Wed, Nov 6, 2013 at 3:06 PM, Razique Mahroua
>>> <razique.mahroua at gmail.com> 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 (antonio.s.messina at gmail.com)
>>>> wrote:
>>>>
>>>> On Wed, Nov 6, 2013 at 12:46 PM, Razique Mahroua
>>>> <razique.mahroua at gmail.com> 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
>>>>> (antonio.s.messina at gmail.com)
>>>>> 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
>>>>> antonio.messina at uzh.ch +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 : openstack at lists.openstack.org
>>>>> Unsubscribe :
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>
>>>>
>>>>
>>>> -- br/>antonio.s.messina@@gmail.com
>>>> antonio.messina at uzh.ch +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
>>>
>>>
>>>
>>> --
>>> antonio.s.messina at gmail.com
>>> antonio.messina at uzh.ch +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
>>
>>
>>
>> --
>> antonio.s.messina at gmail.com
>> antonio.messina at uzh.ch +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
> antonio.messina at uzh.ch +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



-- 
antonio.s.messina at gmail.com
antonio.messina at uzh.ch                     +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