[katello-devel] Katello Backend Service Relationships and Architecture

[Eric D Helms]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20121205/db495c8f/attachment.htm>