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 <[email protected]>wrote: > > > On Tue, Sep 4, 2012 at 5:05 PM, Chathuri Wimalasena > <[email protected]>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 >> <[email protected]>wrote: >> >> > On Sat, Sep 1, 2012 at 10:01 AM, Suresh Marru <[email protected]> >> wrote: >> > > On Aug 31, 2012, at 5:23 PM, Amila Jayasekara < >> [email protected]> >> > 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 <[email protected]> >> > 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 < >> [email protected]> >> > 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 >> > >>> >> > > >> > >> > >
