Hi Lahiru,

Thank you for the comments
-----Below is just a hypothetical example
4. Will there be a default resource for an application? e.g.: For Ultrascan
>> default resource for ECHO application is Stampede
>>
> Yes but echo in stampede is not default, not sure why you are giving this
example.

Thank You,
Best Regards,
Eroma


On Sat, Apr 12, 2014 at 8:44 AM, Lahiru Gunathilake <[email protected]>wrote:

> Hi Eroma,
>
> Sorry I am still sleepy, clicked the wrong place.
>
> On Sat, Apr 12, 2014 at 8:38 AM, Lahiru Gunathilake <[email protected]
> >wrote:
>
> > Hi Eroma,
> >
> > Please find my answers inline.
> >
> >
> > On Sat, Apr 12, 2014 at 3:49 AM, Eroma Abeysinghe <
> > [email protected]> wrote:
> >
> >> Hi,
> >>
> >> Few things that came to my mind,
> >> 1. Can we extend current registry to act as an application catalog ?
> >>
> > Yes thats the plan. May be it could be a good idea to write a new
> registry
> class without overwhelming current runtime operations.
>
> > 2. How are we going to enter application details into the catalog? Is it
> >> done by a gateway ADMIN or a Airavata ADMIN? IF a gateway has a
> front-end
> >> to do this are we allowing it? With CIG how it would be?
> >>
> > Mostly this is a one time operation and mostly gateway admin does it. We
> can provide a tool to add/edit/delete applications.
>
> > 3. Are we going to allow an application deployment in a resource to have
> a
> >> state such as ACTIVE/INACTIVE?
> >>
> > No.
>
> > 4. Will there be a default resource for an application? e.g.: For
> Ultrascan
> >> default resource for ECHO application is Stampede
> >>
> > Yes but echo in stampede is not default, not sure why you are giving this
> example.
>
> > 5. Are we going to allow gateways to manage/maintain their application
> >> catalog?
> >>
> > Yes, mostly the gateway admin will do this task.
> Ex: Ultrascan - Gary.
>
> > 6. Are we going to store only metadata related to applications or are we
> >> going to store output results from experiments also ?
> >>
> > Only static application information , ex: executable path.
>
> > 7. Does application catalog need to stores credentials for resources ?
> >>
> > No
>
> Regards
> Lahiru
>
> >
> >> Thank You,
> >> Best Regards,
> >> Eroma
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Apr 10, 2014 at 12:52 AM, Saminda Wijeratne <[email protected]
> >> >wrote:
> >>
> >> > Hi Sachith,
> >> >
> >> > Please find my comments inline
> >> >
> >> >
> >> > On Tue, Apr 8, 2014 at 10:35 AM, Sachith Withana <[email protected]
> >> > >wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > This is regarding the issue
> >> > > Airavata-1126<https://issues.apache.org/jira/browse/AIRAVATA-1126>
> >> > > .
> >> > >
> >> > > I have a few questions regarding the design.
> >> > >
> >> > > 1. Is the Application Catalog going to be queryable?
> >> > >
> >> > Currently we do not have an advance usecase which  requires gateway
> >> users
> >> > needing to query for application definitions or their deployments out
> of
> >> > application catalog. But there might be a scenario which gateway users
> >> > might be interested in selecting deployments based on their static
> >> > configurations and/or dynamic status. For example "allow execution in
> an
> >> > clustered resource which is currently not that busy or capable of
> >> finishing
> >> > the job within 48 hours". We see in Ultrascan, users are given the
> >> choice
> >> > to select the cluster of which they can run their simulation.
> >> > On the other hand querying could be very useful for scheduling
> purposes.
> >> > Thus it is useful feature for Airavata core developers and in rare
> >> > scenarios gateway developers also.
> >> >
> >> > 2. How are you going to handle the multiple deployments of an
> >> application?
> >> > >     going to be multiple Application catalog for each deployment or
> >> one
> >> > App
> >> > > catalog for each deployment describing where the application is
> >> deployed?
> >> > >
> >> > Current offline discussions we had points to having one globus
> >> application
> >> > catalog shared among gateways. Since we still do not have a specific
> >> design
> >> > for this, I'll put forward my general thoughts about the application
> >> > catalog.
> >> >
> >> >    1. Single deployment of Airavata will have only one application
> >> catalog
> >> >    shared among any registered gateways in that Airavata instance.
> >> >    2. An application catalog will contain multiple applications and
> each
> >> >    application may have multiple deployments defined for it.
> >> >    3. Permissions are placed to control which applications are
> >> available to
> >> >    which gateway (Airavata admin will configure this)
> >> >       1. Gateways can list all applications in the application catalog
> >> but
> >> >       they can only access the ones which they have permission
> >> >       2. permission could be defined for different deployments of the
> >> same
> >> >       applications
> >> >       4. Given an application in the application catalog the access
> data
> >> >    and metadata could be considered in to 2 categories which 1) shared
> >> 2)
> >> >    gateway specific. (its still a question where we save gateway
> >> specific
> >> > data)
> >> >    5. Gateways can request deployment details of an application which
> it
> >> >    has permission to.
> >> >    6. Airavata admins can add/remove applications and its deployments,
> >> >    enable/disable permissions for resources defined in the application
> >> > catalog
> >> >    for gateways, activate/deactivate resources defined in application
> >> > catalog
> >> >    for gateway(s) for a period of time or permanently etc.
> >> >
> >> > I'm working on a mindmap to gather all the data relating to an
> >> application
> >> > catalog. I will post it to the list once I have a decent looking one.
> >> >
> >> > Question I do have in my mind is where should the resources such as
> >> > resource paths defined. Whether it should be part of the application
> >> access
> >> > data or should be independent and later linked to application access
> >> data?
> >> > The reason is if we are planning to allow GFac to handle file
> management
> >> > Tasks in future it might be easier to separating out resource paths
> from
> >> > application access data. wdyt?
> >> >
> >> > >
> >> > > --
> >> > > Thanks,
> >> > > Sachith Withana
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Thank You,
> >> Best Regards,
> >> Eroma
> >>
> >
> >
> >
> > --
> > System Analyst Programmer
> > PTI Lab
> > Indiana University
> >
>
>
>
> --
> System Analyst Programmer
> PTI Lab
> Indiana University
>



-- 
Thank You,
Best Regards,
Eroma

Reply via email to