+1 in general for this “requirement”. I was thinking the same thing.
From: "Christie, Marcus Aaron" <machr...@iu.edu> Reply-To: "dev@airavata.apache.org" <dev@airavata.apache.org> Date: Friday, January 6, 2017 at 2:20 PM To: "dev@airavata.apache.org" <dev@airavata.apache.org> Subject: Re: Improving the PGA Install Eric, 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. Thanks, Marcus On Jan 5, 2017, at 2:22 PM, Eric Coulter <coulter...@gmail.com> 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 (homebrew/port?) - 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, though. Cheers, Eric C.
smime.p7s
Description: S/MIME cryptographic signature
