Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Martin Geisler]

Diego Parrilla Santamaría  writes:

> 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

Nice! I poked around a little in the repo and found no mention of Swift?

> [...] 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...).

Sounds cool!

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

I'm unfortunately not coming to Paris, but we can discuss this over
email. The ZeroVM mailinglist would be fine if it's too off-topic for
this list.

In the ZeroVM project, we're mostly (only really) interested in an
interface for Swift since we can embed the ZeroVM sandbox in Swift.

This gives you a Swift cluster where you can execute map-reduce jobs
(from untrusted clients because of the ZeroVM sandbox) directly on the
data. We like say that you can send the code to the data instead of
doing it the other way around.

So that is why I'm focusing on Swift now and will later add support for
starting these ZeroVM jobs to the browser.

-- 
Martin Geisler

http://google.com/+MartinGeisler


pgpTx2xioHhGZ.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Diego Parrilla Santamaría]

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
*CEO*
*www.stackops.com  | * diego.parri...@stackops.com |
+34 91 005-2164 | skype:diegoparrilla



On Thu, Sep 11, 2014 at 9:15 AM, Richard Jones 
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.
>
>
>

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Martin Geisler]

Richard Jones  writes:

Hi,

I'm working on the ZeroVM project at Rackspace and as part of that I'm
writing a JavaScript based file manager for Swift which I've called
Swift Browser:

  https://github.com/zerovm/swift-browser

When writing this, I of course ran in to exactly the problems you
describe below.

> 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

This was the solution I picked first and it was not difficult to get
working. I used this middleware:

  http://blog.yunak.eu/2013/07/24/keystone_cors/

Since I only case about Swift, another solution that I've been using is
to use swauth (or really https://github.com/zerovm/liteauth) which lets
you authenticate to Swift directly. There are thus only a single origin
to consider and the same-origin problems disappear.

> 3. a new web service that proxies all the APIs and serves the static
>Javascript (etc) content from the one origin (host).

That sounds like another good alternative. I'm not sure familiar with
how people normally deploy Swift, but I would imagine that people setup
some proxying anyway to rewrite the URLs to a nicer format.

> I have implemented options 2 and 3 as an exercise to see how horrid
> each one is.
>
>
> == CORS Middleware ==
>
> 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),

If this became a standard part of OpenStack, could one imagine that the
default WSGI pipelines would already contain the CORS middleware?

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

I'm unsure why it would have to be different for each service? Would the
services not be configured mostly the same, as in:

  [filter:cors]
  allow_origins = https://static.company.com

> == 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 like this option for the flexibility it gives you.

-- 
Martin Geisler

http://google.com/+MartinGeisler


pgpbntQlgOsos.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Richard Jones]

On 12 September 2014 09:24, Richard Jones  wrote:

> On 12 September 2014 07:50, Adam Young  wrote:
>
>> So, lets have these two approaches work in parallel.  THe proxy will get
>> things goint while we work out the CORS approach.
>>
>
> I will look at submitting my middleware for inclusion anyway then.
>

Submitted to oslo.middleware https://review.openstack.org/#/c/120964/


 Richard
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Richard Jones]

On 11 September 2014 18:00, Robert Collins 
wrote:

> FWIW I'm very much in favour of having a single host API - I was
> looking at doing that in Apache for TripleO deployments anyway, due to
> the better SSL deployment characteristics. We then would register the
> actual single host endpoint in publicURL.
>

Yep, basically.



> How would that work for multiple regions with javascript - can you
> switch hosts fairly easily ?
>

I'm not confident I'm completely across the implications of regions, but I
believe there's nothing about them that makes anything planned here break.


 Richard
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Richard Jones]

On 12 September 2014 07:50, Adam Young  wrote:

>  On 09/11/2014 03:15 AM, Richard Jones 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.
>
>
> I don't think these are mutually exclusive.  I can see people wanting
> either in some deployments.
>

I think I agree :)


== 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.
>
> This is one reason I thought that it should be done by auth_token
> middleware.  The other reason is that I don't think we want to blanket
> accept CORS from everywhere, but instead we should do so based on the
> service catalog.
>

It's very important to understand that CORS is entirely advisory. Nothing
is required to pay any attention to it. Modern browsers do, of course, but
in the absence of a browser initiating a CORS conversation (by sending an
Origin header) the CORS middleware should do nothing whatsoever. A GET
request will still return the body of data requested - it's just that the
browser will see the CORS header and block an application from seeing that
data. Security through access controls, XSS protections, etc. must be
handled by other mechanisms.


For a POC deployment, for a small company, all-in-one,  what you are doing
> shouild be fine, but then, if you were running all of your services that
> way, in one web server, you wouldn't need CORS either.
>

This isn't possible in the current OpenStack model - all the APIs run on
different ports, which count as different origins for cross-origin resource
issues (origin is defined as {protocol, host, port}).


So, lets have these two approaches work in parallel.  THe proxy will get
> things goint while we work out the CORS approach.
>

I will look at submitting my middleware for inclusion anyway then.


 Richard
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Adam Young]

On 09/11/2014 03:15 AM, Richard Jones 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.


I don't think these are mutually exclusive.  I can see people wanting 
either in some deployments.







== 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.
This is one reason I thought that it should be done by auth_token 
middleware.  The other reason is that I don't think we want to blanket 
accept CORS from everywhere, but instead we should do so based on the 
service catalog.


This is for the non-trivial deployment case like MOC:

http://www.bu.edu/hic/projects/massachusetts-open-cloud/

Where one "Horizon" instance is going to have to talk to multiple, 
non-trusted instances for each of the services.  CORS should only be 
acceptable between services in the same service catalog.  Yes, I realize 
this is not security enforcment, it is just one step in the strategy.


For a POC deployment, for a small company, all-in-one,  what you are 
doing shouild be fine, but then, if you were running all of your 
services that way, in one web server, you wouldn't need CORS either.


So, lets have these two approaches work in parallel.  THe proxy will get 
things goint while we work out the CORS approach.




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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Robert Collins]

FWIW I'm very much in favour of having a single host API - I was
looking at doing that in Apache for TripleO deployments anyway, due to
the better SSL deployment characteristics. We then would register the
actual single host endpoint in publicURL.

How would that work for multiple regions with javascript - can you
switch hosts fairly easily ?

-Rob

On 11 September 2014 19:15, Richard Jones  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Supporting Javascript clients calling OpenStack APIs

[Richard Jones]

[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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev