[all][tc][horizon] A web tool which helps administrators in managing openstack clusters
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)