[SAGA-RG] SAGA Resource Package Comments

[Andre Merzky]

Sure, I can create a 'teleskope' resource which is neither a job
submission endpoint nor a filesystem endpoint -- but that is not part
of the use cases we considered for the resource API so far.  The set
of considered use cases is fairly limited actually, and that is, IMHO,
a good thing (TM).   And for those use cases, binding the resource
type to a well defined SAGA service endpoint seems to work reasonably
well.  The intent is *not* to define a resource management interface
for arbitrary resource types -- there are enough solutions for that.

Could you come up with some (even a small number) of convincing and
relevant use cases to motivate the resource API to be more generic and
(slightly) less simple to use?

Best, Andre.


On Wed, Jan 16, 2013 at 6:06 PM, Ole Weidner <ole.weidner at rutgers.edu> wrote:
> +1
>
> That has been my argument for a looong time… separation of concerns.
>
> Resources don't necessarily expose a job submission or file transfer
> endpoint at all, hence job/file handling shouldn't be part of the resource
> API!
>
> - Ole
>
> On Jan 16, 2013, at 16:46 , Steve Fisher <dr.s.m.fisher at gmail.com> wrote:
>
> If you create your resource by instantiating an image of a virtual machine
> then that resource may offer a variety of services. Even if you ask some
> kind of resource factory for a resource offering services with certain
> capabilities it may still include other services.
>
> Steve
>
>
> On 16 January 2013 13:47, Andre Merzky <andre at merzky.net> wrote:
>>
>> 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
>
>
>



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

-- Phil Karlton