1019053 - Update Loop-Server Stage with the latest master

Status: VERIFIED FIXED

(Cloud Services :: Operations: Deployment Requests - DEPRECATED, task)

Description

[James Bonacci [:jbonacci]]

We can have :alexis add the necessary branch/release information here...

Comment 1

[Bob Micheletto [:bobm]]

I'll build and push this.

Comment 2

[Tarek Ziadé (:tarek)]

Alexis, we should tag I guess.

Comment 3

[Bob Micheletto [:bobm]]

Latest master has been pushed to stage, there was the following error output during the restart: 
events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Redis connection to loo-ca-goccuvt046my.jk7o1z.0001.use1.cache.amazonaws.com:6379 failed - read ETIMEDOUT
    at RedisClient.on_error (/data/loop-server/node_modules/redis/index.js:185:24)
    at Socket.<anonymous> (/data/loop-server/node_modules/redis/index.js:95:14)
    at Socket.EventEmitter.emit (events.js:95:17)
    at net.js:440:14
    at process._tickCallback (node.js:415:13)
connect: res.on("header"): use on-headers module directly

It otherwise appears to be running.  Please verify.

Comment 4

[James Bonacci [:jbonacci]]

Hmmm, that looks not so good.
I will see if I can get some tests to hit Stage.
Right now, the load test seems broken.

Comment 5

[James Bonacci [:jbonacci]]

:alexis - did you want something newer than master/0.4.0-DEV on Stage and Prod?

Comment 6

[James Bonacci [:jbonacci]]

OK, my guess is, at the very least, we will want these changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1019416
https://github.com/mozilla-services/loop-server/pull/87

Comment 7

[Alexis Metaireau (:alexis)]

the latest master is what we want there, thanks!

I'll tag master with what we released.

Bob, I'm not sure to understand what this was, I guess it just means redis timed out, but not sure why and when.

Comment 8

[Tarek Ziadé (:tarek)]

Alexis, Bob has to fake a version in the RPM in order to ping the release. I would rather increment versions as tags so we're not confused on this. If the current master is our release candidate, let tag a new version for clarity

Comment 9

[Alexis Metaireau (:alexis)]

Tagged 0.4.0 at https://github.com/mozilla-services/loop-server/releases/tag/0.4.0

That would be helpful to me to understand how we can trigger a change on the stage environment. Anyone in ops can provide information about that?

Should we open a new bug each time we want to deploy a new version or is there a better way to deal with this?

Comment 10

[Edwin Wong [:edwong]]

:alexis - usually we deploy on a train schedule, where we lot a bug to trigger that task, create a branch, push that to stage, test it, then log another bug to push that build to production.  For incremental changes - we should have a dev stack that gets auto deployed or self-service deployed by dev for each commit.  We should talk about our approach for deploys.  For FxA we pushed to prod weekly during early dev, then bi-weekly once we were released/stable.

Comment 11

[James Bonacci [:jbonacci]]

and yes, we should open a new bug each time. :-)
Two actually: one for each deployment to loop-server Stage, the other for each deployment to loop-server Production. The first is always a dependency for the second.

Comment 12

[Bob Micheletto [:bobm]]

(In reply to Alexis Metaireau (:alexis) from comment #9)
> Tagged 0.4.0 at
> https://github.com/mozilla-services/loop-server/releases/tag/0.4.0
> 
> That would be helpful to me to understand how we can trigger a change on the
> stage environment. Anyone in ops can provide information about that?
> 
> Should we open a new bug each time we want to deploy a new version or is
> there a better way to deal with this?

Tagging with semantic versioning + separate stage and production deployment bugs is the way to go.  Keeping a stage deployment bug open through QA and subsequent bugfix re-deployments before a given release is pushed to production seems to work pretty well.

Comment 13

[James Bonacci [:jbonacci]]

Already done and tested.