airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Coulter <coulter...@gmail.com>
Subject Re: Improving the PGA Install
Date Thu, 12 Jan 2017 22:22:15 GMT
Thanks, Marcus - that's a good point!

I'll definitely keep "minimally separate" dev/prod deployments in mind,
whichever way we go.

Right now, I'm leaning towards Ansible as a quick solution (< 1 day to
implement & lightly test, unless I'm missing something in the install
guide), but Docker seems like an interesting way to go. It *does* look like
it would involve building a few different containers for the individual
services involved php app, mysql, rabbitmq, and airavata itself.

If noone objects, I'll probably take an hour or two tomorrow to see how far
a quick attempt at 'Ansiblizing' this goes - even if the PGA goes in a new
direction in the future, a small amount of work might save some pain in the
meantime.

Cheers,
Eric C.


On Fri, Jan 6, 2017 at 2:34 PM, Pierce, Marlon <marpierc@iu.edu> wrote:

> +1 in general for this “requirement”. I was thinking the same thing.
>
>
>
> *From: *"Christie, Marcus Aaron" <machrist@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.je@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.
>
>
>

Mime
View raw message