Open Stack

Douglas Zhang wrote:
> [...]
> As Adrian Turjak said:
> 
>     The first major issue is that you connect to the databases of the
>     services directly. That's a major issue, both for long term
>     compatibility, and security. The APIs should always be the main
>     point of contact and the ONLY contract that the services have to
>     maintain. By connecting to the database directly you are now relying
>     on a data structure that can, and likely will change, and any
>     security and sanity checking on filters and queries is now handled
>     on your layer rather than the application itself. Not only that, but
>     your dashboard also now needs passwords for all the databases, and
>     by the sounds of it all the message queues.
> 
> And as Mohammed Naser said:
> 
>     While I agree with you that querying database is much faster, this
>     introduces two issues that I imagine for users: [...]
> 
>     *   also, it will make maintaining the project quite hard because I
>         don't think any projects expose a /stable/ database API.
> 
> Well, we’re not surprised that our querying approach would be challenged 
> since it does sound unsafe. However, we have made some efforts to solve 
> problems which have been posed: [...]
> 
> I hope my explanation is clear enough, and we’re willing to solve other 
> possible issues existing.

Thanks for the replies!

As I highlighted above, you did not address the main issue raised by 
Adrian and Mohammed, which is that the database schema in OpenStack 
services is not stable. Our project teams only commit to one public API, 
and that is the REST one.

Querying the database directly is definitely faster (both in original 
coding and query performance), but you incur enormous technical debt by 
taking this shortcut. *Someone* will have to care about keeping 
openstack-admin queries and projects database schema in sync forever 
after. That means projects either need to commit to a stable database 
API in addition to a stable REST API, *or* openstack-admin maintainers 
will have to keep up with any database schema change in any future 
version of any component they interact with.

At this point in the history of OpenStack, IMHO we need to care more 
about long-term sustainability with a limited number of maintainers, 
than about speed. There are definitely optimizations that can be made to 
make the slowest queries faster, without incurring massive technical 
debt that will have to be repaid by maintainers forever after.

It's definitely less funny and rewarding than writing a superfast new 
database-connected dashboard, but I'd argue that it is where development 
resources should be spent today...

-- 
Thierry Carrez (ttx)