[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: web consoles as broker plugins


For me, cons #3 is the worst point. It prevents any service isolation in order to freelly grow the infrastructure.

Despite this being a limitation imposed by current developer console, it should be addressed in a sense to allow any future console apps to be detached from backend (thinking here in a pure webapp/js+rest web console).

In fact, we (getupcloud) are talking about building a pure webapp for developers, isolated from broker network segment. Maybe even a static-only console version (html+js+assets) to be served from a CDN. But those are only ideas for now. None was done yet.

Mateus Caruccio
Master of Puppets
+55 (51) 8298.0026
gtalk: mateus caruccio getupcloud com
twitter: @MateusCaruccio

This message and any attachment are solely for the intended
recipient and may contain confidential or privileged information
and it can not be forwarded or shared without permission.
Thank you!

On Fri, Jul 5, 2013 at 12:30 PM, Luke Meyer <lmeyer redhat com> wrote:
I'd like to solicit some feedback on this before getting too deep into it and see what pieces of the puzzle I may be unaware of.

We're beginning work on adding an administrative console - a webapp dashboard of sorts for administrators to visualize and navigate some basic OpenShift entities (initially read-only). Draft PEP is at https://github.com/openshift/openshift-pep/blob/master/openshift-pep-001.md (very much a work in progress).

Since this will involve pulling in basically all the same domain concepts as are already present in the broker, the thought has been to provide this as a broker plugin (a rails engine). In that case, it could be optionally added to the broker app via configuration and would use the same process space.

We could consider the same for the developer console, though it performs all access via the REST API and doesn't share anything in the way of actual domain objects. Still, having a completely separate server for it, or even just a separate Passenger instance, seems unnecessary.

Now for some implementation nitty-gritty. The way we have things today, the broker host httpd (where authentication is likely configured) proxies /broker to the broker application bound to localhost and running in a single Passenger instance scoped to the /broker URI ("RackBaseURI /broker"). So anything that runs in the broker space has to begin with /broker and if httpd is responsible for authentication, it occurs based on this URI as well. This is not ideal for the admin console, which isn't conceptually "part of" the broker, authenticates separately (if at all), and which may need to proxy differently (or, not at all).

Is there really a thought that we will ever add another Passenger definition to the /broker one now existing?

My thought was to remove "RackBaseURI /broker" from the Passenger broker conf and just adjust the broker routes scope, which now begins with "/rest" to be "/broker/rest" (any routes added by plugins would need to be similarly adjusted). The broker doesn't have any assets to worry about so that seems to be all that is necessary; I did this and ran the API tests and all passed, so this seems viable.

This would enable mounting the admin console at "/admin-console" on the localhost server without having it automatically proxied externally - administrators could choose to configure access to that however they wanted (proxying, port-forwarding, auth). There are certainly other ways to handle this; it just seems the simplest conceptually. Likewise, just mount the developer console at /console in the same app.

Some pros of this approach:
1. Fewer optional services to chkconfig/start and account for during upgrades/outages.
2. Simpler proxy/auth config at the host httpd.
3. Fewer processes taking up memory and initialization time.

Some cons:
1. Coupling components like this potentially raises the complexity of the app / bloats each process.
2. Is there a potential security risk in external-facing broker app sharing process space with admin functions?
3. Have to have a broker running where you want an admin console (already required for developer console due to auth requirements).

What else have I not considered?

dev mailing list
dev lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]