[katello-devel] Katello Backend Service Relationships and Architecture

[Eric Helms]

Continuing the trend of using pictures to try to express architecture 
since that typically is the easiest way, I have attempted to produce 
three different forward looking architecture diagrams.  To the best of 
my understanding of the various potential architecture designs, the 
links below are intended to show what the Katello architecture would 
look like if all backend services were re-structured to fit the given 
design with associated relationships.

Notes:
* Arrows indicate direction of knowledge ( A -> B meaning A knows about 
B but not vice versa)
* Attempted to incorporate Foreman only, Pulp only, Candlepin only, 
Katello only and joint models in each diagram to show the integration points

Designs:

Remote Resources:
https://docs.google.com/drawings/d/17C-1xxIh1iuHPfKcfV1Q7s0X579uzhBxhMVWkkw17vU/edit

Glue Layer:
https://docs.google.com/drawings/d/1QD5VFgEncwhnCg6Jt7Kd8ViR2dHjkmFc5J0CKJJBpzk/edit

Glue Layer + Remote Resources Layer:
https://docs.google.com/drawings/d/1vVhePWvq_ktnRLf0o3-WhKD2i9dpngcjd1oMNrxIiMM/edit


-Eric


On 12/13/2012 06:35 AM, Petr Chalupa wrote:
>
>
> On 12.12.12 16:11, Lukas Zapletal wrote:
>> On Wed, Dec 12, 2012 at 03:49:17PM +0100, Petr Chalupa wrote:
>>> If you have any additional questions about the Foreman please send
>>> me an email and I'll prepare answers for deep dive tomorrow.
>>
>> I am the most interested in comparing the Foreman and our current
>> approach among each other. Benefits, drawbacks, differences.
>>
>
> This is how I see it, I hope its comprehensive. Please comment if I've 
> missed something.
>
> ## Benefits
>
> By introducing other layer of objects to represent remote resources 
> we've got:
> - less fat models
> - better responsibility separation
> - objects to talk to when crud operations are needed on a remote 
> resource (e.g. Foreman::ArchitectureController and its Api relative 
> are doing that)
> - Resources::AbstractModel is prepared to usage in other back-ends (if 
> we decide to use it)
>
> ## Drawbacks
>
> - additional layer which is not present in other backends - inconsistency
> - headpin packaging (I am not exactly sure what went wrong there.)
>
> ## Differences
>
> I am not aware of any other differences than the ones I've mentioned 
> in previous email.
>
> _______________________________________________
> 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/20121213/29865482/attachment.htm>