airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierce, Marlon" <>
Subject Re: Improving the PGA Install
Date Fri, 06 Jan 2017 19:34:38 GMT
+1 in general for this “requirement”. I was thinking the same thing.


From: "Christie, Marcus Aaron" <>
Reply-To: "" <>
Date: Friday, January 6, 2017 at 2:20 PM
To: "" <>
Subject: Re: Improving the PGA Install




It’s great to have you working on this.


I’m not sure if this really impacts the decision making process much, but I had a thought.
One need I have for an improved installation process for PGA is to use that as a much easier
to use local development environment. However, the needs for a local development environment
vs a deployed production instance of an application are somewhat different. For example, if
I were using Docker for local development I would want to map my local filesystem into the
Docker instance so that code changes I make are reflected in the app running in Docker.  But
that sort of filesystem mounting wouldn’t be needed when running in production.


If we end up with a Docker configuration for development and one for production app deployments,
it would be good if they could share as much configuration as possible.


Also, just to be clear, I’m just using Docker as an example above to illustrate the point.






On Jan 5, 2017, at 2:22 PM, Eric Coulter <> wrote:


Greetings, all!

As of the new year, I'm funded to help out more with different bits of
the Airavata project and the SGRC. One of the first things I'd like to look at is
improving the installation process for the default PGA. After a meeting
this morning, it seems there are a few options. I'd like to start moving
on one of them pretty soon, but we thought some discussion would be
helpful to see which way might be most useful.

Please take a look at these, and let me know any
thoughts/feedback/preferences, or any useful experience with the tools
mentioned! (They are in no particular order.)

1. Continue to use Ansible; develop a role that is as OS-agnostic as
possible (can detect OS, dynamic inventory, etc.) There is already some
work done in this direction, but is this the best place to spend my time?

2. Develop OS-specific packages - rpm, deb, something for mac
 - nice from a "getting other people to host this" viewpoint, but that
doesn't seem to be a huge sticking point.

3. Docker/Singularity? Puppet? Chef? Vagrant? Singularity might be
better for other people in the research space. This would still require
creating different container images for each OS. Does this cause any
problems for database backups? Worth the time to get used to a new tool?

4. Should we be leveraging the tools available from Amazon more heavily?
This might require a fundamental change in the PGA, but could possibly
save a lot of work on our side. We don't know how much it could save,

Eric C.


View raw message