[katello-devel] Katello Backend Service Relationships and Architecture

Wed Dec 12 15:28:01 UTC 2012

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

My biggest issue is that Foreman stuff is all over the place. It was not done following the existing "glue" implementation of pulp and candlepin. As I've said, I really don't have a stake in this decision except for the fact that headpin shares the code base. The pain we've experienced was mostly due with packaging of the headpin RPMs. I am just largely disappointed that the foreman integration didn't join the project as a member with the goal of iterating all the backend services to something better. Instead it just landed with a thump, squashing everything in its way.
</rant>