[katello-devel] Foreman integration and Elastic search

Ivan Necas inecas at redhat.com
Thu Nov 29 09:02:17 UTC 2012



----- Original Message -----
> On 11/27/2012 02:52 PM, Hugh Brock wrote:
> > 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
> >>> into this.
> >> 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.
> >>
> > (cc-ing aeolus-devel)
> >
> > 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.
> Using foreman as a rails engine is very appealing for sure. But
> making it
> work might (almost for sure) be a lot of trouble. As you wrote, TIM
> is
> developed as a Rails Engine, which makes the situation really
> different
> than taking existing standalone Rails app and making it Rails Engine
> ready.
> And that's probably what's Peter's concern about feasibility.
> 
> I would appreaciate Martyn's and Jay's inputs on this concerns.
> 
> I'm also not sure about Foreman community accepting this change. It
> would
> require some changes that complicate the standalone usage (correct
> me,
> if I'm wrong).

One way, however, that Foreman community might benefit from, and would make the
Rails Engines utilization possible, would be breaking Foreman into few more or less independent
engines. That would made possible to have only some subset of Foreman installed and
also to mount this submodules into Katello as well.

-- Ivan

> 
>  From this point, being able to load something to Foreman as a
>  plugin,
> that performs
> some Katello related stuff seems more realistic.
> 
> -- Ivan
> >
> > Take care,
> > --Hugh
> >
> 
> 
> --
> Ivan
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
> 




More information about the katello-devel mailing list