703673 - [tracking] set up a stage for appsync and sauropod

Status: VERIFIED FIXED

(Web Apps Graveyard :: AppsInTheCloud, defect, P1)

Description

[Tarek Ziadé (:tarek)]

we have set a sandbox for the demo, let's make sure now we set up a proper stage (public) RHEL6 infra.

Comment 1

[Ian Bicking (:ianbicking)]

We need two machines (or VMs) for stage, one to host appsync, and another to host Sauropod.

The Sauropod server should be accessible from the appsync server, but otherwise should not be public.  The appsync server will ultimately host a public website (e.g., on https://dev.myapps.mozillalabs.com).

We have RPMs for the appsync setup, though they may need further development; ideally Tarek and I will have root access to debug problems and further develop the packaging, though everything we do will ultimately be either via installed RPMs or a enumerated list of configuration files.  It will also help us setup continuous deployment on the stage server.

The Sauropod deployment is less well defined currently.  Realistically we may need to access the existing (but temporary) dev server from the appsync server, sauropod1.vm1.labs.sjc1.mozilla.com - then once we have the proper sauropod stage box setup (ideally also using RPMs) we can switch over.

Comment 2

[Tarek Ziadé (:tarek)]

Once the box is set up, the AppSync server should be deployable with the RPMs created by the build_rpms command.

The commands to run to create them are:

$ git clone git://github.com/mozilla/appsync.git
$ cd appsync
$ make build_rpms

I propose that we use python26 

Those RPMs should deploy on a fresh RHEL6, with those extra RPMS:

- gunicorn, nginx, python26-setuptools 

In the long term, these RPMs are continuously built by a Jenkins job.

We need to do this for the Sauropod part as well, but like Ian said, maybe we'll access a dev box in the meantime

Comment 3

[Tarek Ziadé (:tarek)]

I've now a Jenkins job that builds the artefacts: 

http://hudson.build.mtv1.svc.mozilla.com/view/9.%20Apps/job/Apps-Sync-RPMS-RHEL6

The RPMs are located here: 

http://hudson.build.mtv1.svc.mozilla.com/job/Apps-Sync-RPMS-RHEL6/lastSuccessfulBuild/artifact/rpms/

Comment 4

[Ian Bicking (:ianbicking)]

There is also a second RPM:

$ git clone --recursive git://github.com/mozilla/openwebapps.git
$ cd openwebapps/site/tools
$ ./build_rpm

On my system this puts the RPM in ~/rpmbuild/RPMS/noarch/myapps-0.1.1.noarch.rpm - but I'm assuming this is particular to my setup.  The RPM cannot be installed until you create a config file, but the config file /etc/myapps.conf containing:

  PROTOCOL=http (or https)
  DOMAIN=some.domain

These are used to rewrite some static files at installation time.  It's a little wonky but seemed like the best way to do it.

Comment 5

[Tarek Ziadé (:tarek)]

> On my system this puts the RPM in ~/rpmbuild/RPMS/noarch/myapps-0.1.1.noarch.rpm -
> but I'm assuming this is particular to my setup

That's rpmbuild default location. Ideally you should provide a "make build_rpms" target that creates them in a local rpms/,

That's useful for Jenkins and for Ops : The Services standard is to grab your repo and run

$ make build build_rpms

and grab the result in rpms/

Comment 6

[Philippe M. Chiasson (:gozer)]

The 2 main VMs are now up and running:
 - sauropod-stage1.vm1.labs.sjc1.mozilla.com
 - myapps-stage1.vm1.labs.sjc1.mozilla.com

@tarek, you have sudo there and can delegate to who you need to.

The HBase VMs are on the way.

Comment 7

[Philippe M. Chiasson (:gozer)]

The HBase VMs are now up and running:

- appsync-hbase-stage1.vm1.labs.sjc1.mozilla.com
- appsync-hbase-stage2.vm1.labs.sjc1.mozilla.com

@rtilder, you have sudo on these 2 and they have an extra 100G disk attached (/dev/vdb) each.

Comment 8

[Philippe M. Chiasson (:gozer)]

(In reply to Ian Bicking (:ianb) from comment #1)
> We need two machines (or VMs) for stage, one to host appsync, and another to
> host Sauropod.
> 
> The Sauropod server should be accessible from the appsync server, but
> otherwise should not be public.  The appsync server will ultimately host a
> public website (e.g., on https://dev.myapps.mozillalabs.com).

Can we make that https://stage-myapps.mozillalabs.com instead ?

Comment 9

[Philippe M. Chiasson (:gozer)]

https://stage-myapps.mozillalabs.com/ is now live (and 404ing)

Comment 10

[Bill Walker [:bwalker] [@wfwalker]]

Per Phillippe, this is resolved.