[GSA-RG] Minutes GSA-RG Telecon Nov 17, 2006

[Ariel Oleksiak]

Dear All,

I uploaded the JSDL profile and scheduling attributes documents at forge.
They are available at: https://forge.gridforum.org/sf/go/doc14009?nav=1 and 
https://forge.gridforum.org/sf/go/doc14026?nav=1, respectively.

Best regards,
Ariel

----- Original Message ----- 
From: "Ramin Yahyapour" <ramin.yahyapour at udo.edu>
To: "Thomas Röblitz" <roeblitz at zib.de>
Cc: <gsa-rg at gridforum.org>
Sent: Friday, November 17, 2006 12:33 PM
Subject: Re: [GSA-RG] Minutes GSA-RG Telecon Nov 17, 2006


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi Thomas,
>
> thanks for the comments:
>
>>> - Negotiation Protocol
>>>   o the protocol will support the gathering of time availability
>>> information
>>>     specific for a request.
>>
>> There exist several approaches for this. For example, a mechanism
>> developed within the Askalon system (paper at SC'06), work on placements
>> of reservations (by Krzysztof Rzadca, me and other colleagues at ZIB;
>> papers in CPE and @EuroPar-2006), and more (by Ramin?).
>
> Yes, there are several approaches to this.
> Thus, I assume it should not be too difficult for Oliver.
> As far as I understood, he already had something for this.
>
>>>   o two-phase commit, extended state-diagram for pre-reservation (to
>>> support e.g. co-allocation)
>>>   o problem: failure of brokers during comittment in pre-reservation
>>>     currently not further investigated,
>>>     for a later stage: "Paxos" seems like a suitable protocol to deal
>>> with reliable committments (see work by Jon MacLaren)
>>
>> I don't think 2PC or Paxos is sufficient. Paxos might help you if a
>> broker crashes, but not if one of the selected resources is not
>> responding. What you need is a decision within a certain period of time?
>> If you're interested in our (TU Berlin & ZIB) findings, we could discuss
>> this (on 27th Nov.).
>
> Not sure about "decision within a certain period of time".
> The problem is actually on the broker level.
> Common example: You try to co-allocate two resources and have to issue the 
> final
> commit that you get them both or none. To this end, we have a reliable
> pre-reservation in a two-phase commit. This usually works fine.
> However, if in the 2PC the second server (or the communication to him) 
> fails during the final
> commitment you end up with an unwanted committed agreement for the first 
> resource.
> Even a three/four-phase commit etc will lessen but not resolve the 
> problem.
>
> Here, Paxos seems reasonable as it can cope with broker failure during the
> commitment phase. Jon showed some results to this extent.
>
>
> Ramin
>
>>
>> Cheers,
>>
>>  Thomas
>>
>>> Attached are some minutes from today's telecon.
>>> Can also be found here:
>>> http://forge.gridforum.org/sf/go/doc14029?nav=1
>>>
>>> Philipp, I do not know whether you also took notes.
>>> Feel free to update the minutes.
>>>
>>>
>>> Ramin
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -- 
>>>   gsa-rg mailing list
>>>   gsa-rg at ogf.org
>>>   http://www.ogf.org/mailman/listinfo/gsa-rg
>>
>
>
> - --
> Dr.-Ing. Ramin Yahyapour         | mailto:Ramin.Yahyapour at uni-dortmund.de
> University of Dortmund           | phone: (+49) 0231/755-2735
> IRF-IT                           | mobil: (+49) 0179/5261973
> 44221 Dortmund / Germany         | fax:   (+49) 0231/755-3251
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.4 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFXZ4gVmlOotJWGRYRAvtUAKCz/1TPZggEU7ZbdpmmJ+uInqZ7ZwCfY4kd
> 1aHntt9IV1YV+bIiH5hJJ3c=
> =PDXz
> -----END PGP SIGNATURE-----
> --
>  gsa-rg mailing list
>  gsa-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/gsa-rg
>