[SAGA-RG] SAGA Resource Package Comments

[Steve Fisher]

I am not even going to attempt it. I just find general solutions are easier
to understand and work with than specific ones and are likely to have a
longer life.

Steve


On 16 January 2013 19:00, Andre Merzky <andre at merzky.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/saga-rg/attachments/20130117/d6eddb26/attachment.html>