Fwd: Re: Improving the PGA Install

[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

["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