[horizon] patternfly?

Thomas Goirand zigo at debian.org
Tue Jun 23 22:51:38 UTC 2020


Hi Ivan,

Thanks for giving your perspective.

On 6/23/20 4:02 PM, Ivan Kolodyazhny wrote:
> 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’.

In what way containers are helping here? Hiding the dirt under a carpet
called "container" doesn't make me feel any safer.

The type of exploit we're expecting to meet with JS is more like XSS, or
XSR. I'm not expecting to ever see an exploit where one escapes from the
web browser, and get inside the server hosting Horizon. Containers
aren't helping for XSS/XSR.

Or are you suggesting something else?

> 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.

I'm really not convinced by that point of argumentation. It has been
written in this tread multiple times, but I don't see why switching
technology spawns new contributors out of nowhere.

> 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.

That'd be great, indeed. Refactoring is always a good idea,
auto-generated UI from a yaml file feels like a very good idea.

Though, as an operator, I really would prefer the switch from
local_settings.py to a normal .ini to move forward. That's IMO more
important than any internal redesign. Horizon is a real pain to
configure (from both the package maintainer perspective with plugins,
and from the configuration management side (puppet in my case)). Do we
have any hope with this for Victoria?

Cheers,

Thomas Goirand (zigo)



More information about the openstack-discuss mailing list