[all][tc][horizon] A web tool which helps administrators in managing openstack clusters
On Fri, Aug 23, 2019 at 3:21 AM Adrian Turjak <adriant at catalyst.net.nz>
> 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
> 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
> 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.
Michael Krotscheck did a bunch of work to put CORS config in many API
services. Why bother with a proxy when we can continue that? :)
> 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. :(
> 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
> *# Highlights*
> Comparing with the current user interface, openstack-admin has following
> *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
> *# 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?
> Douglas Zhang
-------------- next part --------------
An HTML attachment was scrubbed...