[Pulp-list] Messaging Questions

[Todd B Sanders]

On 07/12/2010 11:03 AM, Bryan Kearney wrote:
> 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.

At the moment, yes.  The clients will be sending across package profiles 
as part of a reoccuring action, but that will leverage the Rest API.

-Todd
>
> -- bk