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.
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.
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.)
dev mailing list
dev lists openshift redhat com