[katello-devel] Katello Backend Service Relationships and Architecture

Bryan Kearney bkearney at redhat.com
Thu Dec 6 18:04:57 UTC 2012


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




More information about the katello-devel mailing list