On Tue, Nov 27, 2012 at 09:01:39AM +0200, Ohad Levy wrote:
On 11/26/2012 06:42 PM, Dmitri Dolguikh wrote:
>http://guides.rubyonrails.org/engines.html. In short, rails engine is a
>way to embed a slice of functionality into another rails application. If
>I understood this correctly, foreman team has actually started looking
We are looking into it from the other way around, as community
managed plugins to add to foreman.
Hopefully there is no issue with a nested rails engines.
However, I'm not sure what is the difference between API and as a
mountable app, that we share the same db? (hopefully there are no
database table collisions).
Another option, if needed, is to create a foreman plugin for
katello, which knows in which scenarios ES needs to be updated, this
would work nicely with our planned plugin system, and would allow
the katello team to extend foreman when needed.
For what it's worth, we are sort of doing both with at least one Aeolus
project right now. TIM (Template and Image Manager) is developed as a
Rails Engine, and we will integrate it with Conductor as such. This
means that yes, TIM's model objects will be available to Conductor model
and controller classes.
However, TIM also exposes a REST API, and clients are encouraged to use
that rather than go directly to the models; the API is guaranteed stable
while the models are not.
IIUC Rails Engines have a build-in mechanism for namespacing that should
prevent object name collisions, but I'm not an expert on the
subject. Martyn Taylor or Jay Guiditta can provide more details.
My initial thought, though, is that foreman-as-an-engine is a fantastic
idea and should be pursued.
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."