[katello-devel] Katello Backend Service Relationships and Architecture

[Eric Helms]

On 12/13/2012 03:03 PM, Bryan Kearney wrote:
> On 12/13/2012 05:35 AM, Lukas Zapletal wrote:
>> On Wed, Dec 12, 2012 at 10:19:34PM -0500, Eric Helms wrote:
>>> My intent for creating the diagram and bring to light the various 
>>> implementation details surrounding each service was not to raise the 
>>> ActiveResource debate again or to question the Foreman integration.  
>>> As my diagram showed, Candlepin has connections and touches almost 
>>> every layer as did PulpV1 integration. Rather, my goal is to bring 
>>> up a larger conversation about the Katello architecture as a whole 
>>> going forward.  We are at a point where we are migrating to a 
>>> completely new version of one backend service and re-writing a lot 
>>> of the Katello bits aroun d it (Pulp) and simultaneously integrating 
>>> a brand new backend engine (Foreman).  I am of the opinion, and I 
>>> think based on replies that others echo this, that we should have a 
>>> consistent architecture for the integration of backend services into 
>>> Katello.  No matter what ends up being the choice, consistency is key.
>>>
>>> If there are no other agenda items for the Deep Dive tomorrow, 
>>> perhaps we can take that time to discuss the state of each backend 
>>> service integration wise and how we'd like to achieve consistency 
>>> and a separation of concerns throughout the Katello layers.
>>
>> Speaking about integration, I was collecting items in regard to our
>> orchestration and integration issues for several months now:
>>
>> https://fedorahosted.org/katello/wiki/OrchestrationNG
>>
>> I am not sure if this is topic to raise now (definitely not a deep dive
>> topic), but eventually I would like to talk about it.
>>
>> LZ
>>
> I took a read of the thread, and asked Eric for a quick "talk to me 
> like I am a 2 year old" review. This is what I came away with.
>
> The original glue layer attempted to enforce the following practices:
>
> * The controller layer (/controllers and /controllers/api) should not 
> be aware of the backend engine providing the implementation.
> * Any object which the controller would interact with should live in 
> the model tier (/models), since that is standard rails
> * A glue layer (/model/glue) would enhance the model tier and handle 
> reading/writing to the backend.
> * All transport to the backend systems is external (in /lib/resources)
>
> So, things which go against this pattern in the code base (Master) 
> today include:
>
> A) Controllers calling the glue layer directly (see 
> packages_controller.rb)
> B) Model objects which are backend specific (see /models/candlepin/*, 
> and models/foreman/*)
> C) Model objects not living in /app/models.
> D) App specific namespaces (see controllers/foreman)
>
> Eric, have I understood the main issues correctly? My guess is that 
> (C) would be the larger issue in the current codebase, since it would 
> require a level of abstrction be added into the existing foreman and 
> candlepin paths.
Yep - I think you have nicely summarized the biggest issues around 
architecture inconsistency as they stand in Master.
>
> -- bk
>
>
>
>
>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel