[katello-devel] Katello Backend Service Relationships and Architecture

[Tom McKay]

----- Original Message -----
> From: "Eric D Helms" <ericdhelms at gmail.com>
> To: katello-devel at redhat.com
> Sent: Wednesday, December 5, 2012 9:20:06 PM
> Subject: [katello-devel] Katello Backend Service Relationships and	Architecture
> 
> 
> 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)
> 

Definitely room for clean-up in the candlepin layer. I would love to see us move to align with the clean pulp v2 integration style.

> 
> 
> 
> 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