Open Stack

On 22/06/20 10:52 pm, Sean Mooney wrote:
> 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.

Dart and Typescript are still ultimately javascript when built for a web
interface. :P

And Typescript is often used with the majority of projects already if
building deps from npm. I doubt many people would do React without TS
these days, same with Vue.

Don't get me wrong, I do a lot of Django work, and have built more than
a few websites with it using their templates for html, but the web as a
whole is heavily moving to dynamic JS based frontends that talk to APIs.
Almost all the major CMSs are supporting headless deployments, and for
good reason.

The issue with something like Horizon is that it's built on some truly
amazing APIs, and something like a cloud dashboard lends itself so
perfectly to being entirely dynamic js.

>>  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.
Horizon has already done one attempt at migrating to a JS framework, and
that went badly because it was done as a gradual thing that never
finished, but many of the plugins did start migrating to it. So there is
definitely precedent for them to build plugin variants to support any
new Horizon/Dashboard initiative.

As someone who does maintain a few Horizon plugins, I can't exactly say
the current system is all that good either and it limits what I can
achieve a hell of a lot. I'd honestly love an excuse to build them all
better, but can't when the core framework behind Horizon is not ideal.
My options right now are stick with Django/Horizon's framework (which I
mostly have) and deal with a lot of pain based on how the application
limits what kind of interfaces I actually want to build, or rebuild with
AngularJS and waste my life learning a js framework that has no future.
I'm sure you can see that neither option is ideal. :(
>> 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.

In our case, we use Horizon for a public cloud, and there are a lot of
other institutions that use it as a core interface as well. Yes most
sane users will build the base of their infrastructure using Ansible, or
Terraform, but there are many interactions that are easier and nicer via
a good dashboard.

While none of us have the funding power of Google, when compared to
their cloud interfaces, Horizon is awful. In some regards it's better
than AWS, but only superficially, and even Digital Ocean's rather simple
interface is nicer. We have a lot to learn and improve on.

For many people the first interaction they ever have with an OpenStack
deployment is Horizon, and that doesn't always leave a good impression.