[katello-devel] Organization deletion bug, orchestration, testing

[Martin Bacovsky]

On 12/13/2012 04:37 PM, Lukas Zapletal wrote:
> On Thu, Dec 13, 2012 at 04:14:33PM +0100, Miroslav Suchy wrote:
>> User story:
>> As a dev, I want foreign keys, so db watch integrity for us.
> +1
>

Missing foreign keys in Katello were the first thing that scared me when 
I started on the project. I didn't yet accustomed to the idea that the 
rails way is the right way in this case, so +1 from me.

Since when I tried to understand and debug our orchestration for the 
first time I have a feeling that it is a bit unclear and fragile way to 
handle communication between services. Today I came across article about 
messaging [1] and to me it seems a way to go. I know it would be a *big* 
change, but I think it is worth to at least consider it, especially when 
we have messaging broker (QPID) already set up in katello.

Pros I can see:
- decoupling of our codebase - easier to maintain and test, separate 
modules, consistent orchestration for all subsystems
- debugging - with the right tools we can have detailed orchestration 
monitoring for free
- consistency - support for transactions, proven messaging patterns 
would help us to keep data consistent across subsystems. Like DB server 
is good at keeping data healthy (FKs, constraints, transactions), 
similarly  message broker is good at keeping communication between 
system parts healthy. (lets learn from our previous mistakes)
- scalability -  adding new components doesn't pollute our backend that 
much; adding more instances of Foreman would be possible; Katello 
distributed on more physical machines would be easy

Cons I can see:
- probably big changes in the code
- probably not enough experience with messaging in the team

Ideas?

[1] 
http://www.rubyinside.com/why-rubyists-should-care-about-messaging-a-high-level-intro-5017.html