Open Stack

Even if we agreeded that direct DB access was OK (it isn't), it is worth
adding that this tool will not be backwards compatible in any way. It
will always be linked to the current release DB schema. It wouldn't
handle mixed version clouds, or anything even a little out of sync
without a lot of extra complexity.

Horizon, as awful as it is at times, is great in that it is backwards
compatible VERY far, and in fact we have historically run Horizon close
to master, while lagging behind in other services at various versions.


On 27/08/19 9:04 PM, Thierry Carrez wrote:
> 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...
>