The database layer, which acts as a backend for the OpenStack Networking API, has become a critical component as far as performability, scalability, and reliability of the Openstack networking service are concerned.
This session should cover the following points: - Database access APIs Database access is currently spread throughout the plugin. This leads to occasional errors such as atomicity not properly handled, or concurrent updates. The aim here is to discuss alternatives to improve DB logic in OpenStack Networking, possibly leveraging oslo and using other Openstack projects as an 'inspiration' (ie: shamelessly copy). - Database Upgrades During the Grizzly time frame, Mark McClain gave us DB upgrades; we would now like to collect feedback from the developer and user community about whether the current approach is suitable for deployment which chase OpenStack Networking trunk; also it might be worth discussing whether the current approach needs to be tweaked for handling service plugins. - Usage of SqlAlchemy models The aim of this point in the agenda is to discuss how DB models are used in OpenStack Networking, identifying what can be regarded as good practice, and what instead might not be a good practice, especially when the size of the data set increases dramatically. - DB Profiling at scale This point is related to the previous one and is aimed at discussing a set of procedure to asses how the OpenStack Networking database, and the modules operating on it, can be validated at scale. Note: The list of referenced blueprints is provisional
