On Sep 5, 2012, at 8:59 AM, Chathuri Wimalasena <[email protected]> wrote:
> 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. Hi Chathuri, Yes I would still assume user store will be outside the Airavata scope and even authentication and authorized will be handled externally (and Airavata service layers should have hooks for these), but my point is mainly to have a correlation for this users within the Airavata database. As you suggesting adding user_ID to the resource tables should address this. Suresh > > Thanks and Regards, > Chathuri > > On Wed, Sep 5, 2012 at 6:19 AM, Suresh Marru <[email protected]> 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 <[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 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 >>> <[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 >>>>>>> >>>>> >>>> >> >>
