Open Stack

May be it's a bit too late, but in mid 2012 the FIWARE team developed a
horizon clone 100% in Javascript. https://github.com/ging/horizon-js

Sadly, CORS support was not even in roadmap for OpenStack, so the
horizon-js project was not valid for production at that time.

In StackOps we developed Portal to tackle the lack of CORS support. We
wanted to have 100% javascript 'plugins' or 'apps' that could be upgraded
easily in a single and unified user interface. StackOps Portal also
implements a proxy to all the different OpenStack (and not OpenStack) REST
API services. We also wrap authentication and authorization in the proxy:
the javascript plugins do not know about credentials, they are injected in
the proxy/man-in-the-middle software.

Portal has evolved and now it's more like a 'chroot' for safe execution of
javascript apps. And we use it for our own OpenStack extensions
(accounting, rating, billing, monitoring, advanced network management...).

So maybe if you want to discuss about how to proceed in the future for a
100% javascript user interface, maybe we can talk about it in Paris.

Regards
Diego

 --
Diego Parrilla
<http://www.stackops.com/>*CEO*
*www.stackops.com <http://www.stackops.com/> | * diego.parrilla at stackops.com |
+34 91 005-2164 | skype:diegoparrilla



On Thu, Sep 11, 2014 at 9:15 AM, Richard Jones <r1chardj0n3s at gmail.com>
wrote:

> [This is Horizon-related but affects every service in OpenStack, hence no
> filter in the subject]
>
> I would like for OpenStack to support browser-based Javascript API clients.
> Currently this is not possible because of cross-origin resource blocking in
> Javascript clients - that is, given some Javascript hosted on
> "https://horizon.company.com/" you cannot, for example, call from that
> Javascript code to an API on "https://apis.company.com:5000/v2.0/tokens"
> to
> authenticate with Keystone.
>
> There are three solutions to this problem:
>
> 1. the Horizon solution, in which those APIs are proxied by a very thick
>    layer of additional Python API, plus some Python view code with some
>    Javascript on the top only calling the Horizon view code,
> 2. add CORS support to all the OpenStack APIs though a new WSGI middleware
>    (for example oslo.middleware.cors) and configured into each of the API
>    services individually since they all exist on different "origin"
>    host:port combinations, or
> 3. a new web service that proxies all the APIs and serves the static
>    Javascript (etc) content from the one origin (host). APIs are then
> served
>    from new URL roots "/name/" where the name is from the serviceCatalog
>    entry. Static content can be served from "/static/". The serviceCatalog
> from
>    keystone will be rewritten on the fly to point the API publicURLs at the
>    new service. Requests are no longer cross-origin.
>
> I have implemented options 2 and 3 as an exercise to see how horrid each
> one
> is.
>
>
> == CORS Middleware ==
>
> For those wanting a bit of background, I have written up a spec for oslo
> that
> talks about how this could work: https://review.openstack.org/#/c/119485/
>
> The middleware option results in a reasonably nice bit of middleware. It's
> short and relatively easy to test. The big problem with it comes in
> configuring it in all the APIs. The configuration for the middleware takes
> two forms:
>
> 1. hooking oslo.middleware.cors into the WSGI pipeline (there's more than
>    one in each API),
> 2. adding the CORS configuration itself for the middleware in the API's
> main
>    configuration file (eg. keystone.conf or nova.conf).
>
> So for each service, that's two configuration files *and* the kicker is
> that
> the paste configuration file is non-trivially different in almost every
> case.
>
> That's a lot of work, and confusing for deployers. Configuration management
> tools can ease *some* of this burden (the *.conf files) but those paste
> files
> are a bit of a mess :(
>
> Once the config change is in place, it works (well, except for an issue I
> ran
> into relating to oslo.middleware.sizelimit which I'll go into in another
> place).
>
> The implementation hasn't been pushed up for review as I'm not sure it
> should
> be. I can do this if people wish me to.
>
>
> == New Single-Point API Service ==
>
> Actually, this is not horrid in any way - unless that publicURL rewriting
> gives you the heebie-jeebies.
>
> It works, and offers us some nice additional features like being able to
> host
> the service behind SSL without needing to get a bazillion certificates. And
> maybe load balancing. And maybe API access filtering.
>
> I note that https://openrepose.org already exists to be *something* like
> this, but it's not *precisely* what I'm proposing. Also Java euwww ;)
>
>
> So, I propose that the idea of CORS-in-all-the-things as an idea be
> put aside as unworkable.
>
> I intend to pursue the single-point API service that I have described as a
> way of moving forward in prototyping a pure-Javascript OpenStack Dashboard.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141015/cfb3237e/attachment.html>