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)