[katello-devel] Orchestration-ng thoughts

[Dmitri Dolguikh]

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

>
>> One of the possible approaches is where Katello is a producer of messages (
>> reliable, persisted , and deliv ery- acked) , with pulp, candlepin, and
>> foreman acting as subscribers. The subscribe r functional ity can be
>> extracted into plugins/rails engines.
> One of the findings that were shown at the demo is, that you really don't need
> AMQP for this. AMQP is just a transport layer and it would make sense only to
> use for communicating with the subsystems directly, instead of REST calls,
> which is improvement, but not necessary condition.
>
> Are you talking about engines/plugins into Foreman, Candlepin and Pulp, right?
>
> -- Ivan
>
>>
>> Thoughts?
>> -d
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel