Open Stack

On Mon, 2020-06-22 at 16:42 +1200, Adrian Turjak wrote:
> Thomas, I think that's something that downstream maintainers will
> eventually need to seriously consider and figure out, because any modern
> front end service these days will end up being built with npm pieces,
> and various js libraries.
well not nessisarly you are assuming the only way to build a moderen frontend is
via javascript. there are valid alternitives like dart/typescript for frontends.
django is still a vlaid choice too alsthough to play devils advocate the same
packaging proble that exitsts with js and npm once existed with python and pip
but over time distros have packaged python dependcies. im not that famialr with
npm and ho prolific the random dependencies might be any web dev i have done has
been based on php and dart weher we had few dependcies most of which were free standing
so i have never looked at an npm based project with lot and lots of deps, that just sounds
like poor engnierring but both concerns are valid. e.g. not being able to use a modern tool
set and the packaging of the same.
>  Horizon is sadly a terrible example of a
> 'modern' front end service, and it will either need to eventually pivot
> to being a JS based front end, or replaced by one.
i think part of the larger problem would be porting all the existing horizon plugins for the differnt
services like manila or octavia that our outside of horizon core, also from a donw stream product perspective
horizon is proably the component with the least investment and while we have a theme that is applied to 
give it a RedHat look and feel i dont think porting that to work with a new js based implemation would
be high on our product teams backlog so if the burden was too high it could even bring into question if
its worth continuting to maintain in a downstream product.
> 
> The mindset of excluding or avoiding npm dependencies will cripple any
> attempt at any serious javascript development, and given the modern web
> is all JS interfaces, that doesn't particularly bode well for OpenStack
> from a visual interface perspective if the mindset is very anti-js. :(

well to a certin degree if you are using horizon as your way to deploy application and manage them
one openstack you are doing it wrong. you really should be automaing it with ansible or something else
on the other hand i use horizon daliy when im doing dev because im lazy and while i know how to use the cli
i often just fell like using the gui to quickly launch the test vms because my terminal are monitoring logs
and i dont feel like opening yet another ssh seesion.

so dont get me wrong i am glad horizon exits but my requirements for it are basicly that its fast even on broswer that
are running over ssh forwarding from a vm with no gpu accleration. it shoudl provie a clean workflow to just boot a vm
and perferm simple admin task like creating flavor and image or live migration. the current version of horizon more or
less does that.


> 
> On 21/06/20 9:46 am, Thomas Goirand wrote:
> > On 6/19/20 10:03 PM, Mohammed Naser wrote:
> > > Hi everyone,
> > > 
> > > I was wondering if anyone in the community has explored the idea of
> > > implementing PatternFly inside Horizon.  It seems like it shares a lot
> > > of the similar ideas that we use and we could really benefit from using
> > > a common library that already exists with a lot of good UX thought
> > > behind it.
> > > 
> > > I know it's based on React which is a bit of a leap from where Horizon
> > > is today.  However, I'd be curious if the Horizon team is interested in
> > > figuring out a plan to make a migration to something like this happen.
> > > 
> > > Personally, I think I would be able to provide resources to have
> > > someone do this work.  However, if this seems like a huge stretch and
> > > architecture change where it actually makes more sense to stand this up
> > > from scratch (and implement an architecture where the dashboard talks
> > > directly to the APIs?), perhaps we should explore that.
> > > 
> > > I also would like to hear more from our extended community too, as I
> > > think we really need to improve our user interface experience.
> > > 
> > > Thanks,
> > > Mohammed
> > > 
> > > -- 
> > > Mohammed Naser
> > > VEXXHOST, Inc.
> > 
> > Stuff based on npm are *very* difficult to maintain on downstream
> > distributions, because of the way apps are getting dependencies (ie: by
> > the 100s of dependencies, each of them having to be packaged separately
> > as separate libraries).
> > 
> > So, before considering any solution for the web, please consider the
> > amount of work necessary to do the packaging. For example, I would *not*
> > have the bandwidth to package 100s of nmp components.
> > 
> > These are just general remarks, I don't know any specifics about this
> > particular library (just saw its package.json which is as horrifying
> > (from a package maintainer perspective) as any other npm app...).
> > 
> > Cheers,
> > 
> > Thomas Goirand (zigo)
> > 
> 
>