Open Stack

Hi everyone,


I decided to take some break after the initial mail in this thread to get
my minds together about the current state and the future of Horizon.


I was asked about Reactjs/Angular/Vue/etc framework in Horizon several
times during the past few years. My usual answer is something like: it’s
great to have it but we don’t have the capacity to do it right now. We’ve
got experience with Horizon angularization in the past. It led to missed
some features, slower development and outdated JavaScript dependencies. I
really love that effort even while I’m not a fan of AngularJS 1.x. New
panels look better from a user point of view even if we missed some
features we’d got in legacy panels.


Horizon’s mission is to provide an extensible unified web-based user
interface for all OpenStack services. We want to have good UX for everybody
and cover as many features as possible. We should care about plugins too.
Unfortunately, plugins teams are missing contributors each cycle too. So we
need to have as simple solution as possible.


We can’t ignore the JavaScript part of our project. It’s not an option to
have some classic Django-based application with very few JavaScript
dependencies. Users want to have a modern web application with good UX.


Sooner or later we will switch to some NPM-based application. It's the only
way modern web applications could exist. I do understand all the reasons
why operators and packagers don’t like it. Sometimes, I don't even like it
either. Maybe it will be good timing to move to container-based deployment
or use something like ‘nodeenv’.


The reasons why we need NPM packages it’s JavaScript development
infrastructure. Any new library is packaged for NPM. You can not find any
good manual on how to do something avoiding NPM at all. If we want to
attract new UI developers, we have to switch to new technologies which are
a standard in a world of web development.


Speaking about Horizon's future, there is something I would like to have
some time. It’s only my personal opinion, so I’m open for other suggestions
too.


I would like to have a Horizon project as a framework for OpenStack Web UI.
It should contain some really simple mechanism to generate views for API
resources using OpenstackSDK inside. It means we can easily add new pages
for new resources just by adding some JSON/YAML config file to describe new
entities. Such auto-generated views could be customized with HTML/CSS/JS
using whatever framework we choose (React, Vue, etc). Only “edit” and
“create” features should be implemented for this scenario. If you care
about performance, we should support Server Side Rendering (SSR) to allow
Horizon work on any device or a VM.


I don’t think Horizon can drop it’s “backend” to allow UI call APIs itself.
Sometimes we have to do some preliminary processing for API responses, in
other cases, it could depend on networking configuration and security
reasons. We can argue if such a solution is fast enough or not but it’s
something we need to have to provide everything we need for UI.


Of course, we should need to care about plugins too. Once we decide to
implement Horizon Next, we have to re-implement each plugin too.


It’s a huge effort and I hope someday the community will be able to do it.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Tue, Jun 23, 2020 at 4:21 PM Thomas Goirand <zigo at debian.org> wrote:

> On 6/23/20 2:32 AM, Adrian Turjak wrote:
> > Unless you are reviewing all the code yourself before packaging it
> > (which sounds impossible)
>
> Since I'm packaging all of OpenStack, no, that's not possible! Though
> I'm hoping that everyone that's actually using a particular piece of
> code in OpenStack is potentially someone who could raise a security
> concern in this list. There's also the Debian security team which
> constantly reviews CVEs, and fills bugs against my packages when needed.
>
> All of this would go away if we switch to "npm install ... and forget"
> kind of model.
>
> > the most you can really do is follow:
> > https://docs.npmjs.com/packages-and-modules/securing-your-code
> > Or any other vuln scanning toolkits.
>
> The part here that says:
>
> "Auditing package dependencies for security vulnerabilities"
>
> would clearly not be possible with 600+ npm dependencies (like gitlab
> does, for example).
>
> >> In Python, at least, there's a central repository, with administrator
> >> (trying to?) keeping things safe, and the chain of dependency isn't THAT
> >> insane.
> >
> > Oh the js ecosystem is totally broken, but that's what we have to work
> > with, that's where the world of front end interfaces is right now. The
> > best we can do is work with it/around it. :(
>
> Yeah. We absolutely *DO NOT* need to adopt all the bad practices, and
> the best we can do, is work around them. This includes avoiding the
> dependency hell by well selecting which libraries to depend on.
>
> > But really pip isn't much better.
>
> In Javascript, even if a function ABI is backward compatible, there's no
> guarantee of what that function/method will return. The result is
> unnoticed brokenness at many levels.
>
> > You still really want to be auditing
> > your pip and npm libraries versions against known vulnerabilities.
>
> Yeah, just like any other language. Any given program is as weak as its
> weakest dependency.
>
> > I don't have a solution, but packaging each npm dep for an application
> > that is ultimately a js blob that can be compiled anywhere feels kind of
> > redundant to me. I can understand the need for golang or c libraries
> > that need to be compiled locally because a binary compiled somewhere
> > else may not work depending on host differences, but js is js, and where
> > it is compiled doesn't matter one bit really for where it will run (the
> > browser).
>
> In this decade, mostly everyone is actually compiling JS and
> concatenating libraries into a huge file. In this regard, JS is no
> longer any different from other languages. I'd say it's comparable to
> Go, since every program is actually bundling (which is equivalent to
> statically linking) all the libraries. I'm super satisfied that for
> Horizon, we found a nice way to do that (ie: at package install, and
> using triggers whenever a JS dependency package is updated, so that it
> can be rebuilt).
>
> Do you think JS are a special case? They also *must* be free software,
> and easily patch-able, just like any other piece of code.
>
> > The biggest thing for me is that Horizon or any eventual future
> > dashboard for OpenStack needs to adopt modern js standards, frameworks,
>
> Yes, but not at all costs.
>
> > and development processes to remain relevant.
>
> If by "development processes" you are referring to the "npm install and
> don't care" pattern I described above, then hopefully, that's not what's
> going to happen.
>
> > Having downstream
> > maintainers as one of the reason against ever going in that direction,
> > makes ever reaching that future much harder. :(
>
> Who said security and maintainability is easy? :)
>
> Last word (and repeating to make sure my ideas are reaching): this is
> *NOT* a downstream distribution concern *ONLY*. :P
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200623/b14b66d2/attachment.html>