[SAGA-RG] SAGA Resource Package Comments

[Andre Merzky]

Hi Steve,

On Wed, Jan 16, 2013 at 2:33 PM, Steve Fisher <dr.s.m.fisher at gmail.com> wrote:
> Andre,
>
> I like the generality that a resource provides services - however I take
> your point that it does make the users code more verbose. Perhaps
> getService(capability) would do the trick where capability is the set of
> capabilites that you require for the service. It provides at most one
> service.

While this is indeed more compact and simpler, it is still redundant,
isn't it?  e.g., a compute resource will only ever offer a job
service, etc.  If we want to make that less redundant, and to make
that generic getResource() call useful, we would need to reconsider
the way we actually obtain resource handles in the first place -- and
then possibly only have generic resource handles -- is that what you
envision?  Ole, any opinion on this one?

Thanks, Andre.



> Steve
>
>
> On 16 January 2013 12:29, Shantenu Jha <shantenu.jha at rutgers.edu> wrote:
>>
>> On 1/16/13 7:13 AM, Andre Merzky wrote:
>>>
>>> On Wed, Jan 16, 2013 at 1:01 PM, Ole Weidner <ole.weidner at rutgers.edu>
>>> wrote:
>>>>
>>>> Why not? I should be able to use a "network resource" to manage my
>>>> bandwidth
>>>> reservations / allocations, right?
>>>
>>> A network resource is only useful if you can specify what resources it
>>> connects -- that is one of the uses we had for the resource pool,
>>> which I think won't exist anymore in the next version.  So, how would
>>> you specify connectivity?
>>>
>> It is still early days in our understanding, but at some stage possibly,
>> the ability to include
>> networks as a resource will be important. We have not scoped this out yet,
>> but
>> my hope would be that the current design would be "extensible" to
>> other/novel
>> resources as eventually needed, whilst retaining simplicity to address the
>> compute
>> and storage resources that are well known at this stage.
>>
>



-- 
There are only two hard things in Computer Science: cache invalidation
and naming things.

-- Phil Karlton