airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Data structure for Airavata registry data
Date Wed, 05 Sep 2012 05:58:06 GMT
We forgot the Airavata configuration data :-o.
And I'm remembering this at 2am in the morning :-o :-o :-o

Chathuri, can you please add a table to specify airavata configuration
data. Right now all we have is just a bunch of Airavata service urls. But
once things get more stable we may need a more centralized location to keep
rest of the airavata configurations (if any).

Saminda

On Tue, Sep 4, 2012 at 6:46 PM, Saminda Wijeratne <samindaw@gmail.com>wrote:

>
>
> On Tue, 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<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataRegistry2.java>[1]
 which implements four interfaces
>> as DescriptorRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/DescriptorRegistry.java>[2],
>> ProjectsRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/ProjectsRegistry.java>[3],
>> PublishedWorkflowRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/PublishedWorkflowRegistry.java>[4]
>> and UserWorkflowRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/UserWorkflowRegistry.java>[5].
>>
>
> Please give your suggestions and feedback.
>>
>
> This new API is up for a quick review. Each interface is responsible for
> handling different part of the data. The AiravataProvenanceRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataProvenanceRegistry.java>[6]
interface will striaght-away extend AiravataRegistry2[1] (haven't done
> it in the code yet though) since the experiment Id is unique throughout the
> whole system.
>
> 1.
> https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataRegistry2.java
> 2.
> https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/DescriptorRegistry.java
> 3.
> https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/ProjectsRegistry.java
> 4.
> https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/PublishedWorkflowRegistry.java
> 5.
> https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/UserWorkflowRegistry.java
> 6.
> https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataProvenanceRegistry.java
>
>>
>> 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