[katello-devel] Katello Backend Service Relationships and Architecture

[Ivan Necas]

----- Original Message -----
> On Thu, Dec 13, 2012 at 03:03:00PM -0500, Bryan Kearney wrote:
> > The original glue layer attempted to enforce the following
> > practices:
> > 
> > * The controller layer (/controllers and /controllers/api) should
> > not be aware of the backend engine providing the implementation.
> > * Any object which the controller would interact with should live
> > in
> > the model tier (/models), since that is standard rails
> > * A glue layer (/model/glue) would enhance the model tier and
> > handle
> > reading/writing to the backend.
> > * All transport to the backend systems is external (in
> > /lib/resources)
> 
> I know this thread is about Foreman vs others, but since you replied
> to
> my mail I need to write this over and over again. With the current
> orchestration:
> 
> We tightly couple model and orchestration while orchestration should
> be independent. Katello model is just one of the parties we want to
> integrate with.
> 
> We can only orchestrate things that have resources in our database
> and
> for all the others we need to "hack" alternate models to get this
> working.
> 
> We tend to do long running orchestration by hacking model classes
> (like
> org.task_id) which is weird - we are abusing models to do
> orchestration
> work. Those things are mixed.
> 
> Our codebase is difficult to understand - we are building chains of
> callbacks that are deeply hidden in our model objects. Integration
> proces is a simple function with several statements while we spread
> it
> across multiple classes.
> 
> Errors in our model lead to errors in orchestration. While data
> inconsistency in our katello db are really bad, they are much easier
> to
> fix comparing with inconsistencies across multiple backend engines.
> 
> Our orchestration code is pretty untestable as a standalone component
> and the whole codebase is error prone.
> 
> Katello models are error prone because we have so much code logic in
> there, so many hooks, callbacks and validations needed for
> orchestration. They don't need to be there.
> 
> Our unit tests are either testing models with orchestration turned
> off
> or models and orchestration with turned it on. No separation here,
> tests
> are mixed into each other.
> 
> This approach came from foreman where it works pretty well, but
> Foreman's orchestration is more different from Katello than we
> thought
> it will be.

Just note on the difference: Foreman orchestrates mainly with the smart proxy,
and the difference is the proxy barely stores any data, far from what
we do in our subsystems. Also not long-running tasks are involved in
the Foreman orchestration. And also, if something goes from in Foreman
orchestration, the fix consists mainly form editing some config file for dns/dhcp/tftp,
which can be done by the sys admin, and in ideal case he know what is doing.

When something does wrong while calling CP, Pulp or Foreman from Katello,
there is not so straight way to fix that.

> 
> I said it like twenty times and I can say it again: Let's move our
> orchestration out of our models. Let's refactor this while we still
> have
> some chance to do this. Now is the time, once we agree this is the
> "best" approach and maybe rewrite foreman part into this pattern,
> there
> is no easy way out.

+1

> 
> --
> Later,
> 
>  Lukas "lzap" Zapletal
>  #katello #systemengine
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>