Hi Marcus,

I brought it back [1]

Dimuthu

[1]
https://github.com/apache/airavata/commit/78a22163a39a9985d34fa635754ebf9064ee8305

On Mon, Dec 17, 2018 at 8:51 AM Christie, Marcus Aaron <[email protected]>
wrote:

> Hi Dimuthu,
>
> Yes, it's loaded at runtime. See the db_event_manager property in
> airavata-server.properties.  See also [1].
>
> Thanks,
>
> Marcus
>
> [1]
> https://github.com/apache/airavata/blob/33a601fe84d297b11171a1157a2561a451ad9d84/modules/server/src/main/java/org/apache/airavata/server/ServerMain.java#L126-L126
>
>
> On Dec 16, 2018, at 3:57 AM, DImuthu Upeksha <[email protected]>
> wrote:
>
> Hi Marcus,
>
> Thanks for raising this issue. Is that a runtime dependency? For me,
> everything compiled without db-event-manager [1]. Can you point me to the
> place where we are using that?
>
> [1] https://travis-ci.org/apache/airavata/builds/465830628
>
> Thanks,
> Dimuthu
>
> On Wed, Dec 12, 2018 at 6:22 AM Christie, Marcus Aaron <[email protected]>
> wrote:
>
>> Hi Dimuthu,
>>
>> Thanks for cleaning things up!  However, I'm pretty sure we're still
>> using db-event-manager to manage our event-based synchronization between
>> Airavata services.
>>
>> The rest looks good to be removed though.
>>
>> Thanks,
>>
>> Marcus
>>
>> On Dec 10, 2018, at 1:08 AM, DImuthu Upeksha <[email protected]>
>> wrote:
>>
>> Hi Folks,
>>
>> I removed following modules on staging branch [1] and created a separate
>> branch named archive to keep old changes.
>>
>> allocation-manager
>> cloud
>> db-event-manager
>> gfac
>> integration-tests
>> monitoring
>> test-suite
>> workflow
>> workflow-model
>> xbaya
>> xbaya-gui
>>
>> Following modules were kept as there are some dependencies to other
>> modules
>>
>> compute-account-provisioning
>> configuration
>> security
>>
>> Updated repository was tested in the Testing environment and everything
>> seems to be running smoothly. I will redeploy Staging setup in few days and
>> merge changes to develop branch as well.
>>
>> Thanks
>> Dimuthu
>>
>> [1] https://github.com/apache/airavata/tree/staging/modules
>>
>> On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru <[email protected]> wrote:
>>
>>> Hi Sudhakar,
>>>
>>> The allocation manager from last year contributions is here -
>>> https://github.com/apache/airavata-sandbox/tree/master/allocation-manager 
>>> the
>>> one Dimuthu is suggesting to clean up is a stale one.
>>>
>>> I think we should turn the allocation manager into a larger goal of
>>> enforcing quotas mainly for user storage and probably take on as soon as
>>> possible.
>>>
>>> Cheers,
>>> Suresh
>>>
>>> On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V <
>>> [email protected]> wrote:
>>>
>>> What is the estimated timeline for enforceable allocation management to
>>> be available in Airavata, 2019, 2020?
>>>
>>> Thanks,
>>> Sudhakar.
>>>
>>> *From: *DImuthu Upeksha <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Friday, November 30, 2018 at 8:30 AM
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Re: Unused modules
>>>
>>> Hi Suresh,
>>>
>>> +1 for removing gfac modules as well
>>>
>>> Dimuthu
>>>
>>> On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata <[email protected]>
>>> wrote:
>>>
>>> +1 to remove all of them. While you are at it, should we also remove
>>> gfac modules from develop and staging branches?
>>>
>>> Suresh
>>>
>>>
>>>
>>> On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha <[email protected]>
>>> wrote:
>>>
>>> Hi Folks,
>>>
>>> I can see that some modules [1] are no longer being used or actively
>>> developed.
>>>
>>> allocation-manager
>>> cloud
>>> compute-account-provisioning
>>> configuration
>>> db-event-manager
>>> integration-tests
>>> monitoring
>>> security
>>> workflow
>>> workflow-model
>>> xbaya
>>> xbaya-gui
>>>
>>> I'm suggesting to remove these unused modules as they affect the build
>>> time and the clarity of the code. Any objections / suggestions?
>>>
>>> [1] https://github.com/apache/airavata/tree/staging/modules
>>>
>>> Thanks
>>> Dimuthu
>>>
>>>
>>>
>>
>

Reply via email to