[katello-devel] Katello Backend Service Relationships and Architecture

Eric Helms ehelms at redhat.com
Thu Dec 13 03:19:34 UTC 2012 

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.

-Eric

----- Original Message -----
From: "Petr Chalupa" <pchalupa at redhat.com>
To: katello-devel at redhat.com
Sent: Wednesday, December 12, 2012 9:49:17 AM
Subject: Re: [katello-devel] Katello Backend Service Relationships and	Architecture

I am not sure if I understand it correctly, so I've decided to send my 
version to make sure that we are on the same track.

## Legend

- black edges are representing knowledge dependency as before
- red represents modules and direction in which they are included 
(Interpretation id: what knowledge ActiveRecord model gains when a 
module is included)
- green represents services
- 1) in reality there is one step skipped, instantiation of an object 
from foreman_api gem and creating a singleton, see [1]

## Where I see differences

- Candlepin doesn't have a Rubygem with Ruby bindings, they are placed 
in /lib
- In Foreman there is one additional layer "Remote resource 
representation". Objects of the layer are replacing lazy_accessors and 
they are introducing missing separation between data from Katello and 
remote service.
- There are no controllers with full CRUD to manipulate with non-Katello 
data in Pulp or Candlepin. There are in Foreman and they are using added 
representation of remote resources.

## Implementation notes

- All classes in "Remote resource representation" are children of 
Resources::ForemanModel which is representation of any Foreman remote 
resource. Resources::ForemanModel is inheriting from 
Resources::AbstractModel which is representation of any remote resource. 
(AbstractModel  could also by used for Candlepin and Pulp)

More documentation is on wiki [2]

If you have any additional questions about the Foreman please send me an 
email and I'll prepare answers for deep dive tomorrow.

Petr

[1] 
https://github.com/Katello/katello/blob/pulpv2/src/lib/resources/foreman.rb
[2] https://fedorahosted.org/katello/wiki/ForemanIntegrationAPI

## Other resources

There were at least 3 long threads about this topic I think. I didn't 
have luck finding them but if you want I can try harder.


On 06.12.12 19:04, Bryan Kearney wrote:
> On 12/05/2012 09:20 PM, Eric D Helms wrote:
>> They say a picture is worth a thousands words, and after, for lack of a
>> better word, being bugged by the differences in backend service
>> integration I decided to try and spell out the current lay of the land.
>>   I have attempted to do this in two ways.  The first being a diagram
>> showing how our models, glue and controllers are laid out in relation to
>> backend services with arrows indicating the directional awareness that
>> one entity has with another.  For example, an arrow pointing from
>> glue/candlepin to resources/candlepin since glue/candlepin has direct
>> knowledge of the resources but not vice versa.  Second, I have attempted
>> to quell out into bullet points how each backend service is currently
>> (and by this I mean as of PulpV2 branch) integrated.
>>
>> Disclaimer:  This is my understanding of things and there are places
>> where I could have gotten something wrong or mis-represented that actual
>> implementation
>>
>> Reference Diagram:
>> https://docs.google.com/drawings/d/1lK-BozdUbTBJPnvSv40uCtzy4_Y1qUZCIJesq_pqsHY/edit
>>
>>
>> Note: This is taking into consideration the changes made in the PulpV2
>> branch and current Candlepin and Foreman work in master
>>
>>
>> *PulpV2*
>>
>> - All Pulp functionality is contained within app/models/glue/pulp
>> - All glue layers are modules that are included into the Katello model
>> if use_pulp = true
>> - Katello Models are treated as the main entity, with Pulp glue layer
>> adding functionality if included
>> - Even non-persisted objects have a top-level representation in Katello
>> (e.g. errata, package, distribution)
>> - Nothing is proxied
>> - Basic functionality is orchestrated (CRUD)
>> - Use of callbacks and hooks to trigger top-level events that can be
>> listened to by glue layer
>> - There is no notion of pulp outside the glue layer
>>
>>
>> *Candlepin*
>>
>> - Contains a single Candlepin only model without corresponding inclusion
>> in a Katello entity (OwnerInfo)
>> - Contains some proxied functionality mainly for subscription manager
>> - Not all Candlepin functionality is contained in glue layer
>> - Basic functionality is orchestrated (CRUD)
>>
>>
>> *Foreman*
>>
>> - Foreman is front and center at all layers
>> - Controllers for API and UI are under foreman/ and namespaced
>> - Models are under foreman/ and are classed as Foreman::
>> - Katello models that have corresponding Foreman model also get a
>> separate model file besides their glue layer counterpart (i.e.
>> models/foreman/user)
>> - Other models have lightweight representations and are entirely pass
>> through objects down to Foreman but are not top-level Katello entities
>> - Glue layer is fenced off and only included if use_foreman set to true
>>
>>
>> *ElasticSearch*
>>
>> - All ES functionality is contained within app/models/glue/elasticsearch
>> - All glue layers are modules that included into the corresponding
>> Katello model
>> - Adds functionality but does not directly impart itself into the models
>> - Use of callbacks and hooks to trigger top-level events that can be
>> listened to by glue layer
>>
>>
>> I am hoping this will spark some discussion, as I worry that the
>> differences in integration points for each backend service will only
>> make our lives as developers more difficult down the road.
>>
>> -Eric
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>
> I agree with the Deep Dive. Dmitri had expressed similar concerns. Who
> from € wants to set this up?
>
> -- bk
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

_______________________________________________
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