<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Bah, sent it via my phone and didn't hit reply all.<br>
</p>
<div class="moz-cite-prefix">On 26/08/19 10:55 PM, Jim Rollenhagen
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJCXu8e1XDgJinbc1AJLRpm7pTY9YHxxQ6z2vdhCvj3oNv3gyA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Fair points. In case you didn't realize, you only
sent this to me, not the list :)<br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><br>
// jim</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Aug 24, 2019 at 1:45
AM Adrian Turjak <<a href="mailto:adriant@catalyst.net.nz"
moz-do-not-send="true">adriant@catalyst.net.nz</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 24 Aug. 2019 00:08, Jim
Rollenhagen <<a
href="mailto:jim@jimrollenhagen.com" target="_blank"
moz-do-not-send="true">jim@jimrollenhagen.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail-m_4373309676727564987quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">On Fri, Aug 23, 2019 at 3:21 AM
Adrian Turjak <<a
href="mailto:adriant@catalyst.net.nz"
target="_blank" moz-do-not-send="true">adriant@catalyst.net.nz</a>>
wrote:<br>
</div>
<div
class="gmail-m_4373309676727564987elided-text">
<blockquote style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<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>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">We deploy our dashboard publically, but our
APIs are behind a whitelist only firewall. I bet we're not
the only one. So we need the proxy like nature of the
dashboard API calls.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I personally like the idea of the browser
able to talk to the APIs directly, but I have a feeling
there may be other reasons to avoid that. Not to mention
you get a clearer picture of which API calls come from the
dashboard. Plus, a proxy via the dashboard app itself
(assuming it is deployed near the cluster) won't exactly
add much extra to the response time.</div>
<div dir="auto"><br>
</div>
<div dir="auto">But if we as a community do end up going
down this route, we can discuss if we need the app to
proxy or not. If not, then really we are just building a
pure JavaScript app, but if we do need to proxy, then the
proxy layer would still be very simple with the core logic
all in the front-end.</div>
<div dir="auto">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail-m_4373309676727564987quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div
class="gmail-m_4373309676727564987elided-text">
<blockquote style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<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>On 20/08/19 10:14 PM, Douglas Zhang
wrote:<br>
</div>
<blockquote>
<div dir="ltr">
<div style="font-size:small">
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">Hello everyone,</p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">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)</p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><b># Introduction</b></p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">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 <code style="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> 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.</p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><b># Highlights</b></p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">Comparing with the current user interface, openstack-admin has following advantages:</p>
<ul style="margin:0.8em
0px;padding-left:30px">
<li style="margin:0px">
<p style="line-height:inherit;margin:0px 0px 0.5rem;white-space:pre-wrap"><strong>Fast</strong>: 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).</p>
</li>
<li style="margin:0px">
<p style="line-height:inherit;margin:0px 0px 0.5rem;white-space:pre-wrap"><strong>Flexible</strong>: 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.</p>
</li>
<li style="margin:0px">
<p style="line-height:inherit;margin:0px 0px 0.5rem;white-space:pre-wrap"><strong>User-friendly</strong>: 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.</p>
</li>
</ul>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap"><b># Issues</b></p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">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.</p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">So that’s all. How do you guys think of this project?</p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">Thanks,</p>
<p style="line-height:inherit;margin:0.8em 0px;white-space:pre-wrap">Douglas Zhang</p>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>