airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <thejaka.am...@gmail.com>
Subject Re: Data structure for Airavata registry data
Date Sat, 01 Sep 2012 15:08:28 GMT
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
View raw message