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@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)