[katello-devel] Katello Backend Service Relationships and Architecture

[Bryan Kearney]

On 12/13/2012 05:35 AM, Lukas Zapletal wrote:
> On Wed, Dec 12, 2012 at 10:19:34PM -0500, Eric Helms wrote:
>> My intent for creating the diagram and bring to light the various implementation details surrounding each service was not to raise the ActiveResource debate again or to question the Foreman integration.  As my diagram showed, Candlepin has connections and touches almost every layer as did PulpV1 integration. Rather, my goal is to bring up a larger conversation about the Katello architecture as a whole going forward.  We are at a point where we are migrating to a completely new version of one backend service and re-writing a lot of the Katello bits aroun d it (Pulp) and simultaneously integrating a brand new backend engine (Foreman).  I am of the opinion, and I think based on replies that others echo this, that we should have a consistent architecture for the integration of backend services into Katello.  No matter what ends up being the choice, consistency is key.
>>
>> If there are no other agenda items for the Deep Dive tomorrow, perhaps we can take that time to discuss the state of each backend service integration wise and how we'd like to achieve consistency and a separation of concerns throughout the Katello layers.
>
> Speaking about integration, I was collecting items in regard to our
> orchestration and integration issues for several months now:
>
> https://fedorahosted.org/katello/wiki/OrchestrationNG
>
> I am not sure if this is topic to raise now (definitely not a deep dive
> topic), but eventually I would like to talk about it.
>
> LZ
>
I took a read of the thread, and asked Eric for a quick "talk to me like 
I am a 2 year old" review. This is what I came away with.

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)

So, things which go against this pattern in the code base (Master) today 
include:

A) Controllers calling the glue layer directly (see packages_controller.rb)
B) Model objects which are backend specific (see /models/candlepin/*, 
and models/foreman/*)
C) Model objects not living in /app/models.
D) App specific namespaces (see controllers/foreman)

Eric, have I understood the main issues correctly? My guess is that (C) 
would be the larger issue in the current codebase, since it would 
require a level of abstrction be added into the existing foreman and 
candlepin paths.

-- bk