Open Stack

Hello Douglas!

As someone who has struggled against the performance issues in Horizon I
can easily feel your pain, and an effort to making something better is
good. Sadly, this doesn't sound like a safe direction, even if for admin
only purposes.

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.

I would highly encourage you to try and work with the community to fix
the issues at the API layers rather than bypassing them. We can add
better query and filtering to the APIs, and we can work on improving
performance if we know the pain points, and this is likely where
contributions would be welcome.

I think we do need an alternative to Horizon, and the ideal solution in
my mind is to make a new dashboard built on either React or Vue, with a
thin proxy app (likely in Flask) that serves the initial javascript
page, and proxies any API requests to the services themselves. The
filter issues should made better by implementing more complex filtering
in the APIs themselves, and having the Dashboard layer better at
exposing those dynamically. React or Vue would do a much better job of
dynamically and quickly reloading and querying the services, and it
would make the whole experience much nicer.

The one of the best parts of Horizon was that it was a 'dumb' dashboard
built around your token. It can be deployed anywhere, by anyone, and
only needs access to the cluster to work, no secrets to any database.

I know this is a huge issue, and we do need to solve it, but I hope we
can work on something better that doesn't bypass the APIs, because that
isn't a safe solution. :(

Cheers,

Adrian Turjak

On 20/08/19 10:14 PM, Douglas Zhang wrote:
>
> Hello everyone,
>
> To help users interact with openstack, we’re currently developing a
> client-side web tool which enables administrators to manage their
> openstack cluster in a more efficient and convenient way. (Since we
> have not named it officially yet, I’m going to call it openstack-admin)
>
> *#Introduction*
>
> Some may ask, “Why do we need an extra web-based user interface since
> we have horizon?” Well, although horizon is a mature and powerful
> dashboard, it is far not efficient enough on big clusters (a simple
> |list|operation could take seconds to complete). What’s more, its
> flexibility of searching could not match our requirements. To overcome
> obstacles above, a more efficient tool is urgently required, that’s
> why we started to develop openstack-admin.
>
> *#Highlights*
>
> Comparing with the current user interface, openstack-admin has
> following advantages:
>
>  *
>
>     *Fast*: openstack-admin gets data straightly from SQL databases
>     instead of calling standard openstack API, which accelerates the
>     querying period to a large extent (especially when we’re dealing
>     with a large amount of data).
>
>  *
>
>     *Flexible*: openstack-admin supports the fuzzy search for any
>     important field(e.g. display_name/uuid/ip_address/project_name of
>     an instance), which enables users to locate a particular object in
>     no time.
>
>  *
>
>     *User-friendly*: the backend of openstack-admin gets necessary
>     messages from the message queue used by nova, and send them to the
>     frontend using websocket. This way, not only more realistic
>     progress bars could be implemented, but more detailed information
>     could be provided to users as well.
>
> *#Issues*
>
> To make this tool more efficient and provide better support for
> concurrency, we chose Golang to implement openstack-admin. As I’ve
> asked before (truly appreciate advises from Jeremy and Ghanshyam), a
> project written by an unofficial language may be accepted only if
> existing languages have been proven to not meet the technical
> requirements, so we’re considering re-implementing openstack-admin
> using python if we can’t come to an agreement on the language issue.
>
> So that’s all. How do you guys think of this project?
>
> Thanks,
>
> Douglas Zhang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190823/791d5ff4/attachment-0001.html>