Open Stack

Hi Joe,

Thanks for pointing me to an interesting discussion on this issue.

I'm wondering if you're aware of any tool/IDE to debug the database
interactions (like by setting  a "breakpoint") of openstack components. I'm
interested in understanding the code flow vis-a-vis database interactions
for Nova and Neutron components, to begin with. I've currently configured
PyCharm editor (since it allows us to look into both source code & database
tables). I would appreciate your input on this.

Thanks.



---
Regards​,
Arun Adiththan


On Thu, Mar 19, 2015 at 1:21 AM, Joe Topjian <joe at topjian.net> wrote:

> I think that particular scenario in the Ops Guide could be considered a
> bit outdated, but the subject in general is still relevant.
>
> I've found that in each release of OpenStack, the various OpenStack
> components are better able to reclaim / resolve orphaned resources, such as
> the floating IP scenario described. In fact, I haven't had a need to
> manually update the databases for anything for at least the past three
> releases.
>
> But situations still exist. I think the big one at the moment is the issue
> of quota skewing. There's a good discussion on the openstack-operators list
> about a possible solution:
>
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-March/006517.html
>
> On Tue, Mar 17, 2015 at 3:36 PM, Arun Adiththan <arunadiththan at gmail.com>
> wrote:
>
>> ​OpenStack Operations Guide talks about some of the potential data
>> inconsistency errors in openstack databases.
>>
>> "... an instance was terminated, but the status was not updated in the
>> database" [1]
>>
>> "Sometimes an instance is terminated but the floating IP was not
>> correctly de-associated from that instance. Because the database is in an
>> inconsistent state, the usual tools to dissaociate the IP no longer work.
>> To fix this, you must manually update the database." [2]
>>
>> I'm wondering whether manually inspecting the database is the only way to
>> identify such data inconsistency errors. If so, I think it could be a
>> tedious process since we have a large number of tables in each openstack
>> component database and may not clearly know which ones should be queried to
>> detect the potential inconsistencies.
>>
>> [1] http://docs.openstack.org/openstack-ops/content/maintenance.html
>>
>> [2]
>> http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html
>> ---
>> Regards​,
>> Arun Adiththan
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150321/5064d1ea/attachment.html>