[Pulp-list] Messaging Questions

[Bryan Kearney]

On 07/12/2010 10:48 AM, Todd B Sanders wrote:
> On 07/12/2010 10:22 AM, Bryan Kearney wrote:
>> On 07/12/2010 09:08 AM, Todd B Sanders wrote:
>>> On 07/08/2010 05:06 PM, Jason Dobies wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>>> Open questions which I see:
>>>>>
>>>>> 1) Does pulp require durable queues? Do I want to ensure that a packge
>>>>> is updated the next time it wakes up? If so, we need to handle queue
>>>>> purging. Perhaps this is tied to consumer deletion.
>>>>>
>>>>> 2) Can the same message (install package) be sent P2P Sync, Fire and
>>>>> Forget, and broadcast. I think the answer to this should be yes. If
>>>>> so,
>>>>> in broadcast, is there a notion of the success/failure?
>>>> 1 and 2 are kinda related, so I'll answer both here.
>>>>
>>>> This is a really interesting question. If a user says to install a
>>>> package and the agent isn't currently available, will the user still
>>>> want it installed in the future when it is available?
>>>>
>>>> I think if we add a time factor to the request (i.e. "only do this if
>>>> you get the message before 8am") I'm more inclined to go with only
>>>> using
>>>> durable queues for package installs. It feels like too critical of an
>>>> operation to leave open to a non-guaranteed paradigm.
>>>>
>>>>> 3) Will Jason Dobies choose to argue against himself who is arguing
>>>>> against himself? if so, is he correct no matter what the outcome?
>>>> I'm glad you came to the realization that I'm always correct. :)
>>>>
>>>>> 4) Is there a hearbeat requirement? I have not heard of any.
>>>> It's starting to sound like there is. If we go durable queues, this is
>>>> gonna be the way we clean up queues for dead agents. Even if there
>>>> isn't, I think it's a trivial enough addition to give us minimalistic
>>>> availability information. Good bang for the buck there.
>>>
>>> We sort of had this with Satellite and rhn-check. Out of the box,
>>> managed systems check in with the server every 4-hours. We then
>>> high-light inactive systems. Seems to me that a heartbeat is a good way
>>> to achieve similar information. So, IMO, it is a requirement.
>>>
>>> -Todd
>>
>> Do you envision the heartbeat over rest, or AMQP?
>
> Was chatting with jortel about this. Thinking AMQP will be more
> efficient. No tcp/http overhead.
>


Is this the only client initiated AMQP Call? I am trying to figure out 
the AMQP/Rest split.

-- bk