[katello-devel] Katello Backend Service Relationships and Architecture

[Eric D Helms]

On Thu, Dec 6, 2012 at 10:37 AM, Lukas Zapletal <lzap at redhat.com> wrote:

> Quick look on the picture shows one thing - folks who were implementing
> foreman layer took different approach. I'd like to see them to organize
> deep dive showing us how it works, what is/was the motivation, so we can
> have further discussion about which approach is better.
>
> It's definitely not good to have different approaches for the same
> things. The picture shows this pretty nicely.
>
> ps - why there are arrows from foreman controllers and API to Candlepin?
> do I miss something for this particular case?
>

The boxes reflect sort of the "filesystem" and "class/module" structure as
well as knowledge relationships. So in this case, the "UI" controllers have
direct references to the Resources as well as the API controllers for
Candlepin.  The foreman box inside the controllers might just be too close
to the arrow anchor point.

-Eric


> Thanks for this, Eric!
>
> LZ
>
> On Wed, Dec 05, 2012 at 09:20:06PM -0500, 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
>
>
> --
> Later,
>
>  Lukas "lzap" Zapletal
>  #katello #systemengine
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20121206/007a7500/attachment.htm>