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 <[email protected]> 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 <[email protected]> > 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 : [email protected] >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> >
_______________________________________________ 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
