<div dir="ltr"><div dir="ltr">On Fri, Aug 23, 2019 at 3:21 AM Adrian Turjak <<a href="mailto:adriant@catalyst.net.nz">adriant@catalyst.net.nz</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p>Hello Douglas!<br>
      <br>
      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.<br>
    </p>
    <p>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.<br>
      <br>
      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.<br>
      <br>
      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. <br></p></div></blockquote><div>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? :) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
      <br>
      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.<br>
      <br>
    </p>
    <p>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. :(<br>
    </p>
    <p>Cheers,</p>
    <p>Adrian Turjak<br>
    </p>
    <div class="gmail-m_-1442438405121442788moz-cite-prefix">On 20/08/19 10:14 PM, Douglas Zhang
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div style="font-size:small">
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">Hello everyone,</span></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">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)</span></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><b><span style="box-sizing:border-box">#</span><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box"> Introduction</span></b></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">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 </span><span style="box-sizing:border-box"><code style="box-sizing:border-box;border:1px solid rgb(231,234,237);background-color:rgb(243,244,244);border-radius:3px;padding:0px 2px;font-size:0.9em">list</code><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box"> 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.</span></span></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><b><span style="box-sizing:border-box">#</span><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box"> Highlights</span></b></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">Comparing with the current user interface, openstack-admin has following advantages:</span></p>
          <ul class="gmail-m_-1442438405121442788gmail-ul-list" style="box-sizing:border-box;margin:0.8em 0px;padding-left:30px">
            <li class="gmail-m_-1442438405121442788gmail-md-list-item" style="box-sizing:border-box;margin:0px">
              <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0px 0px 0.5rem;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-" style="box-sizing:border-box"><strong style="box-sizing:border-box"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">Fast</span></strong><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">: 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).</span></span></p>
            </li>
            <li class="gmail-m_-1442438405121442788gmail-md-list-item" style="box-sizing:border-box;margin:0px">
              <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0px 0px 0.5rem;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-" style="box-sizing:border-box"><strong style="box-sizing:border-box"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">Flexible</span></strong><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">: 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.</span></span></p>
            </li>
            <li class="gmail-m_-1442438405121442788gmail-md-list-item" style="box-sizing:border-box;margin:0px">
              <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0px 0px 0.5rem;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-" style="box-sizing:border-box"><strong style="box-sizing:border-box"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">User-friendly</span></strong><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">: 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.</span></span></p>
            </li>
          </ul>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><b><span style="box-sizing:border-box">#</span><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box"> Issues</span></b></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p gmail-m_-1442438405121442788gmail-md-focus" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain gmail-m_-1442438405121442788gmail-md-expand" style="box-sizing:border-box">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.</span></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">So that’s all. How do you guys think of this project?</span></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">Thanks,</span></p>
          <p class="gmail-m_-1442438405121442788gmail-md-end-block gmail-m_-1442438405121442788gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><span class="gmail-m_-1442438405121442788gmail-md-plain" style="box-sizing:border-box">Douglas Zhang</span></p>
        </div>
      </div>
    </blockquote>
  </div>

</blockquote></div></div>