airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chathuri Wimalasena <kamalas...@gmail.com>
Subject Re: Data structure for Airavata registry data
Date Wed, 05 Sep 2012 12:59:36 GMT
Hi Suresh,

I understand your point. I was under the impression that these users are
the ones coming from outside, as the users who are using the client
application which is built using airavata. I'm wondering whether do they
need to know about hosts and services. Experiment table contains user
information. I will add user_ID to Project table and other descriptors.

Thanks and Regards,
Chathuri

On Wed, Sep 5, 2012 at 6:19 AM, Suresh Marru <smarru@apache.org> wrote:

> Hi Chathuri,
>
> Should we not have a owner (user_ID) correlated in each of the resource
> tables (projects, experiments, all descriptors)? For instance, how will the
> following query traverse:
>
> Retrieve all the projects belonging to User A belonging to gateway X?
>
> Similarly, retrieve all service descriptions owned by User A (contained
> within gateway x)?
>
> Cheers,
> Suresh
> On Sep 4, 2012, at 5:05 PM, Chathuri Wimalasena <kamalasini@gmail.com>
> wrote:
>
> > Hi All,
> >
> > Following is the updated structure after the discussion we had regarding
> > the $subject.
> >
> > gateway *
> >  |- descriptors *
> >  |- published workflows *
> >  |- users *
> >  |       |- workspace
> >  |       |      |- workflows
> >  |       |      |- projects *
> >  |       |             |- experiments *
> >  |       |
> >  |
> >  |
> >  |
> >  |
> >  |- name
> >  |- owner
> >  |
> >  |
> >
> > According to above structure, database table structure is also changed as
> > below.
> >
> > Gateway
> >  gateway_ID
> >  gateway_name
> >
> > Users
> >  user_ID
> >  user_name
> >  password
> >
> > Projects
> >  project_ID
> >  gateway_ID
> >  project_name
> >
> > Published_Workflow
> >  gateway_ID
> >  workflow_name
> >  version
> >  content
> >  published_date
> >
> > User_Workflow
> >  project_ID
> >  user_ID
> >  workflow_name
> >  last_update_date
> >
> > Host_Descriptor
> >  gateway_ID
> >  host_descriptor_ID
> >  host_descriptor_xml
> >
> > Service_Descriptor
> >  gateway_ID
> >  service_descriptor_ID
> >  service_descriptor_xml
> >
> > Application_Descriptor
> >  gateway_ID
> >  application_descriptor_ID
> >  service_descriptor_ID
> >  host_descriptor_ID
> >  application_descriptor_xml
> >
> > Experiment
> >  project_ID
> >  user_ID
> >  experiment_ID
> >  submitted_date
> >
> > New Registry API was committed under r1380866 and the class name is
> > AiravataRegistry2 which implements four interfaces
> > as DescriptorRegistry, ProjectsRegistry, PublishedWorkflowRegistry
> > and UserWorkflowRegistry.
> >
> > Please give your suggestions and feedback.
> >
> > Thanks and Regards,
> > Chathuri
> >
> >
> >
> > On Sat, Sep 1, 2012 at 11:08 AM, Amila Jayasekara
> > <thejaka.amila@gmail.com>wrote:
> >
> >> On Sat, Sep 1, 2012 at 10:01 AM, Suresh Marru <smarru@apache.org>
> wrote:
> >>> On Aug 31, 2012, at 5:23 PM, Amila Jayasekara <thejaka.amila@gmail.com
> >
> >> wrote:
> >>>
> >>>> Hi Suresh,
> >>>>
> >>>> Could you please elaborate what you meant by "1 project owned by a
> >>>> single user" ?
> >>>> I am trying to figure out what sort of actions are allowed when a user
> >>>> is an "owner" of a project.
> >>>
> >>> Hi Amila,
> >>>
> >>> The data privacy is a complex topic, thats one of the long term best
> >> interests of Airavata to align and reuse the work done by projects like
> >> OODT. In true short term, Airavata registry should suffice and keep the
> >> focus on maturing the core features and bring them to a 1.0 state. Back
> on
> >> the topic, by default users would like to keep data and metadata private
> >> for a certain time. This window varies from use case to use case, but
> >> roughly it will be 12 to 18 months. During this time, the user analyses
> the
> >> data or publishes results. This also includes the recipe which was used
> to
> >> generate the data, which in Airavata case is the Workflow and the inputs
> >> and configurations. There is a growing push on depositing data and
> metadata
> >> into public repositories. So summarizing, Airavata should by default
> make
> >> the workflows, projects and experiments within it owned and accessible
> by a
> >> single user or the owner of the data. At the same time, we should
> consider
> >> capabilities to share these data (at experiment or project level) to a
> set
> >> of users, or groups or make them public.
> >>>
> >>> Does this answer your question?
> >>
> >> Hi Suresh,
> >>
> >> Yes it answers my question.
> >>
> >> Also can we assume that descriptors (host, application etc ...) are
> >> owned by a single user ? (In addition to workflows, projects and
> >> experiments)
> >>
> >> Let me also explain how we thought about this.
> >>
> >> A gateway can have multiple projects. A project can have multiple
> >> experiments. An experiment is equivalent to a workflow. So a user is
> >> associated with a workflow. The associated user has read, write
> >> capabilities to all workflows he/she designs.
> >> If a workflow needs to be shared, then it goes to a new state called
> >> "published". In published state other users can read the workflow but
> >> cannot do any modifications to it.
> >>
> >> I guess with your answer we need to change the structure we originally
> >> discussed.
> >>
> >> Thanks
> >> Amila
> >>
> >>
> >>>
> >>> Suresh
> >>>
> >>>> Thanks
> >>>> Amila
> >>>>
> >>>> On Fri, Aug 31, 2012 at 5:08 PM, Suresh Marru <smarru@apache.org>
> >> wrote:
> >>>>> Hi Chathuri,
> >>>>>
> >>>>> This is a very good list. Few suggestions, I think Descriptors and
> >> published workflows should be moved outside and right within Gateways.
> Also
> >> each user might have multiple projects and 1 project is owned by a
> single
> >> user. So I think it should be Users and then multiple projects within
> it.
> >>>>>
> >>>>> Suresh
> >>>>>
> >>>>> On Aug 31, 2012, at 5:02 PM, Chathuri Wimalasena <
> kamalasini@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> We had a discussion on how airavata registry data should be
> >> categorized and
> >>>>>> came up with the following structure.
> >>>>>>
> >>>>>> Gateway
> >>>>>> |- Project1
> >>>>>> |     |- Descriptors
> >>>>>> |     |- Published workflows
> >>>>>> |     |- User A
> >>>>>> |           |- unpublished workflows
> >>>>>> |           |- experiments
> >>>>>> |                    |- workflow
> >>>>>> |                           |- nodes
> >>>>>> |
> >>>>>> |
> >>>>>> |
> >>>>>> |
> >>>>>> |- Project2
> >>>>>> |       |- user A
> >>>>>> |
> >>>>>> |
> >>>>>>
> >>>>>> According to the above structure, below table structure was
designed
> >> for
> >>>>>> the mysql database which will be replacing existing backend
> jackrabbit
> >>>>>> database.
> >>>>>>
> >>>>>> Gateway
> >>>>>> gateway_ID
> >>>>>> gateway_name
> >>>>>>
> >>>>>> Projects
> >>>>>> gateway_ID
> >>>>>> project_ID
> >>>>>>
> >>>>>> Public_Workflow
> >>>>>> project_ID
> >>>>>> workflow_name
> >>>>>> version
> >>>>>> content
> >>>>>> published_date
> >>>>>>
> >>>>>> User_Workflow
> >>>>>> project_ID
> >>>>>> user_ID
> >>>>>> workflow_name
> >>>>>> last_update_date
> >>>>>>
> >>>>>> Host_Descriptor
> >>>>>> project_ID
> >>>>>> host_descriptor_ID
> >>>>>> host_descriptor_xml
> >>>>>>
> >>>>>> Service_Descriptor
> >>>>>> project_ID
> >>>>>> service_descriptor_ID
> >>>>>> service_descriptor_xml
> >>>>>>
> >>>>>> Application_Descriptor
> >>>>>> project_ID
> >>>>>> service_descriptor_ID
> >>>>>> host_descriptor_ID
> >>>>>> application_descriptor_xml
> >>>>>>
> >>>>>> Experiment
> >>>>>> project_ID
> >>>>>> user_ID
> >>>>>> experiment_ID
> >>>>>> submitted_date
> >>>>>>
> >>>>>> All suggestions and feedbacks are most welcome.
> >>>>>>
> >>>>>> Thanks and Regards,
> >>>>>> Chathuri
> >>>>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message