[katello-devel] Orchestration-ng thoughts

[jesus m. rodriguez]

On 04/29/2013 12:43 PM, Dmitri Dolguikh wrote:
> On 2013-04-29 4:30 PM, Ivan Necas wrote:
>>
>> ----- Original Message -----
>>> Thanks, Ivan, for the work on the orche stration NG and the demo
>>> today. This
>>> is a big improvement over the current implem entation , and it's
>>> actually te
>>> stable!
>> The testability was one of my concerns: you can test the execution plan,
>> then the action itself, and the finalization phase separately, without
>> mocking or so.
>>> I would like to figure out if the orchestration approach is something
>>> we want
>>> to stick with, or should we switch to a me ssaging-based (amqp?)
>>> approach?
>>> We would if not completely get ri d of orchestrat ion, but at the
>>> very least
>>> significantly reduce the a mou nt of it.
>> I don't see how you would get rid of orchestration in Katello? You can
>> get
>> rid of the REST calls and replace it with AMQP, but AMQP wont solve
>> the logic
>> for you.
>>
>> The Dynflow implementation is agnostic on the transport or persistent
>> layer.
>> I can imagine the actions that occur there to not be persisted in
>> database,
>> but sent with amqp instead (in fact, messaging was one think that I
>> started
>> with at the beginning).
>>
>> Dynflow is also ready for this: that's why there is a way how to
>> define the
>> format of the actions, so that the interface is defined.
>
> I don't think using AMQP simply as a transport while keeping existing
> architecture in place is worth the effort.
> Instead in such an approach, Katello would publish messages to a fanout
> queue. The rest of the systems would subscribe to that queue and consume
> messages from it. The queue would provide reliable delivery and
> acknowledgement of messages.
>
> The main effort I suspect would be in changing orchestration so that: a)
> data moves in one direction and b) operations on each of the subscribed
> systems are independent of each other.

We talked about using AMQP *back in the day* :)

https://engineering.redhat.com/trac/satellite/wiki/HybridApproach

And the idea there was that each APP would listen for the 
events/messages they cared about. We never made it past that initial 
document before Katello was born with direct REST calls.

jesus

-- 
jesus m. rodriguez          | jesusr at redhat.com
principal software engineer | irc: zeus
red hat systems management  | 919.754.4413 (w)
rhce # 805008586930012      | 919.623.0080 (c)
+---------------------------------------------+
|   "Those who cannot remember the past       |
|    are condemned to repeat it."             |
|                        -- George Santayana  |
+---------------------------------------------+