You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@airavata.apache.org by Eric Coulter <co...@gmail.com> on 2017/01/05 19:22:50 UTC
Improving the PGA Install
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.
Re: Improving the PGA Install
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
On Feb 2, 2017, at 9:34 AM, Eric Coulter <je...@iu.edu>> wrote:
Meant to sent this to dev as well... updates on my scripts for the PGA follow!
Thanks, Shameera!
1. I did mean only the PGA for now. Thanks for the link; I've got a version up extended for Ubuntu at [1]. Please take a look/test if you've got a chance!
It was fairly straightforward to add support for Debian; the main trip-up was dealing with the differences in http daemon config, but separation of tasks/includes/templates was easy using ansible_os_family as a key for the right filename/variables (added dictionary in roles/pga/vars/main.tml based on OS).
Eric, Dev,
I finally got around to trying to install PGA on Centos on Jetstream. I configured the variables so that it would deploy an instance of PGA to match what we deploy for dev.seagrid.org<http://dev.seagrid.org>. It worked pretty well! Here are some of my thoughts on the process:
* To configure the variables I needed to update roles/pga/vars/main.yml. That is, according to ansible variable precedence [1], there was no good way to just override those variables for my VM on Jetstream. Ideally, I think, I would rather use group variables (or host vars?) for configuring the specifics of a particular pga instance instead of needing to mess around with the pga role. I think maybe we could move roles/pga/vars/main.yml to roles/pga/defaults/main.yml, that way it serves to document the needed variables and provides defaults for variables that don’t need to be overridden often
* I didn’t configure the gateway_data_store_resource_id but I’m bringing this up because if we want to automate provisioning pga instances we’ll need to automate creating the data storage resource especially for new Jetstream VMs and the like.
* I think it would be simpler/safer to add an apache config file to /etc/httpd/conf.d instead of replacing the main httpd.conf file, if we can. It would only need to have a couple of <VirtualHost> configurations.
* it seemed weird that the app/storage and user data directory are made owned (user and group) by the ‘centos’ user instead of by the ‘apache’ user. On gw54 we have these directories owned by a ‘pga’ user and group owned by the ‘apache’ group. It makes sense because httpd runs as user apache. I don’t think this is a huge deal, since the directories are world writeable, just seemed weird.
* I discussed this with Eric on Slack but to document: I couldn’t run just the pga plays in the playbook by using tags. I tried this:
ansible-playbook -i hosts --tags pga site.yml
However it tried to connect to the zookeeper server listed in hosts and failed. It appears that Ansible runs fact gathering on all hosts in the playbook even if they have no matching plays [2]. Eric came up with a workaround:
ansible-playbook -i hosts --tags pga -l pga site.yml
This limits the playbook to only run for the pga host. (Probably the ‘—tags pga’ is superfluous).
But in general, it looks like the tags aren’t so useful. Maybe makes sense to break the single playbook up into some smaller ones.
Thanks,
Marcus
[1] http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable
[2] https://github.com/ansible/ansible/issues/15927#issuecomment-248419553
Fwd: Re: Improving the PGA Install
Posted by Eric Coulter <je...@iu.edu>.
Meant to sent this to dev as well... updates on my scripts for the PGA
follow!
Thanks, Shameera!
1. I did mean only the PGA for now. Thanks for the link; I've got a
version up extended for Ubuntu at [1]. *Please take a look/test if
you've got a chance!*
It was fairly straightforward to add support for Debian; the main
trip-up was dealing with the differences in http daemon config, but
separation of tasks/includes/templates was easy using ansible_os_family
as a key for the right filename/variables (added dictionary in
roles/pga/vars/main.tml based on OS).
3. I might get to take a look at this; I'll have to check out what
Marcus has done and some past discussions on problems with
PGA-as-container. I just mentioned puppet/chef as possible alternatives,
but I am definitely on board with Ansible.
As far as production/dev goes, at least for Ansible (where the main
difference should just be the hosts involved), it would be fairly easy
to re-structure the inventory/variable setup in the root playbook
directory, something like in [2].
[1] https://github.com/ECoulter/airavata/tree/pga_update/dev-tools/ansible
[2]
http://www.geedew.com/setting-up-ansible-for-multiple-environment-deployments/
Cheers,
Eric C.
On 01/12/2017 11:20 PM, Shameera Rathnayaka wrote:
> Hi Eric,
>
> Are you referring PGA by only Php Gateway or the whole set of Airavata
> components (e.g PGA, API Server, Orchestrator, Registry etc)?
>
> Please see my comments Inline.
>
>
> 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?
>
> You can find the ansible scripts written for Linux OS's with RPM
> package manager (This scripts are tested only on CentOS) here [1] .
> But if you replace "yum" package manager with "apt-get" you could
> probably make this script works with Ubuntu as well. Ansible provide
> simple way to handle this as we can include yml files (which has set
> of ansible tasks) based on some conditions. You might consider to
> writing two set of ansible scripts for setup development
> environtment(which use SNAPSHOT version of Airavata) and production
> environtment (which use released version of Airavata).
>
> 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.
>
>
> This is nice to have feature IMO.
>
>
>
> 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?
>
>
> Isn't Puppet, Chef are alternative to Ansible? I haven't worked with
> Singularity but Docker is good way to move forward. Ajinkya already
> have done some works [2] which need to be merged with development
> branch. But it seems that pull request doesn't have a docker image for
> PGA. This might be a good place to you to start. Great if you can
> review the pull request and give some feedback.
>
> Marcus has a valid point, how you think to support development and
> production images and maintain the code for both environtments? Thease
> are open ended questions that we need to find solutions.
>
>
>
> 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.
>
>
> In my experience it is kind of hard to generalize the deployment
> scripts to work out of the box regardles of the environtment. But I
> would say, we should consider minimizing the use of environment
> specific tools.
>
> [1] https://github.com/apache/airavata/tree/develop/dev-tools/ansible
> [2] https://github.com/apache/airavata/pull/67
>
> Regards,
> Shameera.
>
> Cheers,
> Eric C.
>
> --
> Shameera Rathnayaka
--
------------------------------------
Eric Coulter jecoulte@iu.edu
XSEDE Capabilities and Resource Integration Engineer
IU Campus Bridging & Research Infrastructure
RT/PTI/UITS
812-856-3250
Re: Improving the PGA Install
Posted by Eric Coulter <je...@iu.edu>.
Thanks, Shameera!
1. I did mean only the PGA for now. Thanks for the link; I've got a
version up extended for Ubuntu at [1]. *Please take a look/test if
you've got a chance!*
It was fairly straightforward to add support for Debian; the main
trip-up was dealing with the differences in http daemon config, but
separation of tasks/includes/templates was easy using ansible_os_family
as a key for the right filename/variables (added dictionary in
roles/pga/vars/main.tml based on OS).
3. I might get to take a look at this; I'll have to check out what
Marcus has done and some past discussions on problems with
PGA-as-container. I just mentioned puppet/chef as possible alternatives,
but I am definitely on board with Ansible.
As far as production/dev goes, at least for Ansible (where the main
difference should just be the hosts involved), it would be fairly easy
to re-structure the inventory/variable setup in the root playbook
directory, something like in [2].
[1] https://github.com/ECoulter/airavata/tree/pga_update/dev-tools/ansible
[2]
http://www.geedew.com/setting-up-ansible-for-multiple-environment-deployments/
Cheers,
Eric C.
On 01/12/2017 11:20 PM, Shameera Rathnayaka wrote:
> Hi Eric,
>
> Are you referring PGA by only Php Gateway or the whole set of Airavata
> components (e.g PGA, API Server, Orchestrator, Registry etc)?
>
> Please see my comments Inline.
>
>
> 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?
>
> You can find the ansible scripts written for Linux OS's with RPM
> package manager (This scripts are tested only on CentOS) here [1] .
> But if you replace "yum" package manager with "apt-get" you could
> probably make this script works with Ubuntu as well. Ansible provide
> simple way to handle this as we can include yml files (which has set
> of ansible tasks) based on some conditions. You might consider to
> writing two set of ansible scripts for setup development
> environtment(which use SNAPSHOT version of Airavata) and production
> environtment (which use released version of Airavata).
>
> 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.
>
>
> This is nice to have feature IMO.
>
>
>
> 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?
>
>
> Isn't Puppet, Chef are alternative to Ansible? I haven't worked with
> Singularity but Docker is good way to move forward. Ajinkya already
> have done some works [2] which need to be merged with development
> branch. But it seems that pull request doesn't have a docker image for
> PGA. This might be a good place to you to start. Great if you can
> review the pull request and give some feedback.
>
> Marcus has a valid point, how you think to support development and
> production images and maintain the code for both environtments? Thease
> are open ended questions that we need to find solutions.
>
>
>
> 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.
>
>
> In my experience it is kind of hard to generalize the deployment
> scripts to work out of the box regardles of the environtment. But I
> would say, we should consider minimizing the use of environment
> specific tools.
>
> [1] https://github.com/apache/airavata/tree/develop/dev-tools/ansible
> [2] https://github.com/apache/airavata/pull/67
>
> Regards,
> Shameera.
>
> Cheers,
> Eric C.
>
> --
> Shameera Rathnayaka
--
------------------------------------
Eric Coulter jecoulte@iu.edu
XSEDE Capabilities and Resource Integration Engineer
IU Campus Bridging & Research Infrastructure
RT/PTI/UITS
812-856-3250
Re: Improving the PGA Install
Posted by Shameera Rathnayaka <sh...@gmail.com>.
Hi Eric,
Are you referring PGA by only Php Gateway or the whole set of Airavata
components (e.g PGA, API Server, Orchestrator, Registry etc)?
Please see my comments Inline.
> 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?
>
> You can find the ansible scripts written for Linux OS's with RPM package
manager (This scripts are tested only on CentOS) here [1] . But if you
replace "yum" package manager with "apt-get" you could probably make this
script works with Ubuntu as well. Ansible provide simple way to handle this
as we can include yml files (which has set of ansible tasks) based on some
conditions. You might consider to writing two set of ansible scripts for
setup development environtment(which use SNAPSHOT version of Airavata) and
production environtment (which use released version of Airavata).
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.
>
This is nice to have feature IMO.
>
>
> 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?
>
Isn't Puppet, Chef are alternative to Ansible? I haven't worked with
Singularity but Docker is good way to move forward. Ajinkya already have
done some works [2] which need to be merged with development branch. But it
seems that pull request doesn't have a docker image for PGA. This might be
a good place to you to start. Great if you can review the pull request and
give some feedback.
Marcus has a valid point, how you think to support development and
production images and maintain the code for both environtments? Thease are
open ended questions that we need to find solutions.
>
> 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.
>
In my experience it is kind of hard to generalize the deployment scripts to
work out of the box regardles of the environtment. But I would say, we
should consider minimizing the use of environment specific tools.
[1] https://github.com/apache/airavata/tree/develop/dev-tools/ansible
[2] https://github.com/apache/airavata/pull/67
Regards,
Shameera.
Cheers,
> Eric C.
>
--
Shameera Rathnayaka
Re: Improving the PGA Install
Posted by Eric Coulter <co...@gmail.com>.
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 <ma...@iu.edu> wrote:
> +1 in general for this “requirement”. I was thinking the same thing.
>
>
>
> *From: *"Christie, Marcus Aaron" <ma...@iu.edu>
> *Reply-To: *"dev@airavata.apache.org" <de...@airavata.apache.org>
> *Date: *Friday, January 6, 2017 at 2:20 PM
> *To: *"dev@airavata.apache.org" <de...@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 <co...@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.
>
>
>
Re: Improving the PGA Install
Posted by "Pierce, Marlon" <ma...@iu.edu>.
+1 in general for this “requirement”. I was thinking the same thing.
From: "Christie, Marcus Aaron" <ma...@iu.edu>
Reply-To: "dev@airavata.apache.org" <de...@airavata.apache.org>
Date: Friday, January 6, 2017 at 2:20 PM
To: "dev@airavata.apache.org" <de...@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 <co...@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.
Re: Improving the PGA Install
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
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 <co...@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.
Re: Improving the PGA Install
Posted by Shameera Rathnayaka <sh...@gmail.com>.
Hi Eric,
Are you referring PGA by only Php Gateway or the whole set of Airavata
components (e.g PGA, API Server, Orchestrator, Registry etc)?
Please see my comments Inline.
> 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?
>
> You can find the ansible scripts written for Linux OS's with RPM package
manager (This scripts are tested only on CentOS) here [1] . But if you
replace "yum" package manager with "apt-get" you could probably make this
script works with Ubuntu as well. Ansible provide simple way to handle this
as we can include yml files (which has set of ansible tasks) based on some
conditions. You might consider to writing two set of ansible scripts for
setup development environtment(which use SNAPSHOT version of Airavata) and
production environtment (which use released version of Airavata).
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.
>
This is nice to have feature IMO.
>
>
> 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?
>
Isn't Puppet, Chef are alternative to Ansible? I haven't worked with
Singularity but Docker is good way to move forward. Ajinkya already have
done some works [2] which need to be merged with development branch. But it
seems that pull request doesn't have a docker image for PGA. This might be
a good place to you to start. Great if you can review the pull request and
give some feedback.
Marcus has a valid point, how you think to support development and
production images and maintain the code for both environtments? Thease are
open ended questions that we need to find solutions.
>
> 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.
>
In my experience it is kind of hard to generalize the deployment scripts to
work out of the box regardles of the environtment. But I would say, we
should consider minimizing the use of environment specific tools.
[1] https://github.com/apache/airavata/tree/develop/dev-tools/ansible
[2] https://github.com/apache/airavata/pull/67
Regards,
Shameera.
Cheers,
> Eric C.
>
--
Shameera Rathnayaka