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

Re: web consoles as broker plugins





On Jul 7, 2013, at 11:46 AM, Krishna Raman <kraman gmail com> wrote:

I wanted to keep it out of the discussion because the integrated web setup is special. It needs to be running while the other components are not. 

Why?  There's no real reason why the broker has to crash and burn if it's improperly configured, nor is there any real requirement that all the broker setup code is run once.  In fact, over time, as we move to improve how the oo-* scripts boot and load (to reduce their dependence on the entire rails infrastructure) we will already need most of the initialization code to be cleanly abstracted from rails (invoked, but not coupled with).

I'm not putting constraints on how the setup should work, merely highlighting that all of our arguments need to be framed around justifying *why* something is different/special - i.e. not a properly decoupled rails engine that can be hosted in many places.  Choosing to put integrated setup someplace else is a valid decision, made with the understanding that there is a reason to deviate from the norm.

And once it has finished setting everything up, it will be turned off and the others will be turned on. I don't mind it being a plugin, but it most likely 
will not be run in the same process space as the broker or console as the config entered needed by the broker/console plugins would not be present 
while the setup is running.

--kr

On Jul 7, 2013, at 8:35 AM, Clayton Coleman <ccoleman redhat com> wrote:

Mark's right - a component like "integrated web setup" (regardless of when or whether its implemented) is appropriate to mount as a plugin to the broker, and needs the flexibility to be rerouted to a base URL.  It's not broker setup to an end deployer - its OpenShift setup.

Eventually we will absolutely be required to share a number of common web UI components between the various parts of Openshift, especially web assets, layouts, common visual helpers, etc.  Regardless of the app -> passenger -> route topology, we will start sharing the underlying code.  That will allow us to make the right choices here.

The implication beyond that is we need to be developing and integrating *isolated* components, that can be flexibly moved across rails apps in the future.  Things like namespacing our rails plugins (which we aren't great at today), ensuring we keep core library code properly independent, and thinking through cases like these as Luke has done.

On Jul 7, 2013, at 8:36 AM, Mark Lamourine <markllama gmail com> wrote:

Krishna: the reason I put my foot in was because it had stopped being about the admin console and had started being about integrating the web functions in the web application of the broker.  The desire for another component could affect the decision.

In this context I'm just concerned with its presence, not it's requirements (other then being available and avoiding conflct.)

- Mark


On Sun, Jul 7, 2013 at 1:27 AM, Krishna Raman <kraman gmail com> wrote:
Hey Mark,

Harrison and I will be looking into the setup application for prebuilt VM images as part of Origin improvements we have been discussing.
Prefer not to mix that requirement into the discussion about admin console.

--kr

On Jul 6, 2013, at 6:10 PM, Mark Lamourine <markllama gmail com> wrote:

Just to throw gas on the fire, an additional "application" that I'd like to see is a "setup" tool which would be presented to the root (/) of the broker web (possibly by redirect to some other path) when the broker has been installed and started but not configured.

The purpose of this app would be to guide the new implementer through the process of configuring the database information and selecting/configuring the broker plugins. It would not be expected to actually install or setup the back-end services ala an all in one, but might guide the installer to a tutorial for each one as needed.

I'm not suggesting that this be added to existing planned work, I'm just wondering how something like this might fit into the presentation of an extended broker (REST interface, developer app console etc.)

- Mark


On Fri, Jul 5, 2013 at 11:30 AM, 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
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



--
----
Mark Lamourine <markllama gmail com>
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist
_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev




--
----
Mark Lamourine <markllama gmail com>
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist
_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


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