650328 - Deploy KeyExchange server in stage then production

Status: VERIFIED FIXED

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

Description

[Tarek Ziadé (:tarek)]

version 0.3-1

dependencies, see: https://hg.mozilla.org/services/server-key-exchange/file/a849f34f2a77/RELEASE.txt

Comment 1

[Mike Connor [:mconnor]]

Can we make sure all of the reqs at https://wiki.mozilla.org/Services/Process/ServerReleaseProcess#Hand_off_from_Engineering_to_Test_Checklist are covered here?

Comment 2

[:Atoll]

Reassigning to Tarek to address the handoff checklist question from Mike.  Taking no action at this time.

Comment 3

[Tarek Ziadé (:tarek)]

Test plan:
- the /report API triggers a 400 when called without anything to report. It is now gracefully returning a 200 in that case, to avoid the current clients that are calling /report w/o anything to report when the user abort the transaction. (This client behavior was fixed). A side-effect is that the channel gets closed immediately. To try out, create a channel and call report with the right channel and session ids and check that it returns a 200 and that the channel is closed. Note that this is covered by the current functional tests, that are also run by Hudson on the staging server.

Comment 4

[Tarek Ziadé (:tarek)]

the changed functional test that tests this can be found in the changeset: https://hg.mozilla.org/services/server-key-exchange/rev/22cfba3c4aee

Comment 5

[:Atoll]

process variance activated (a=mconnor), as this is the only deploy this week we're going to rebuild it until it works.  new tag coming up and will repeat push until one of them works, and document it here.

Comment 6

[:Atoll]

Updated:
  python26-keyexchange.noarch 0:0.4-1    python26-sqlalchemy.noarch 0:0.6.6-1  

weave-stage-jpake.mv.mozilla.com updated and appear to be responding correctly to basic checks.

Comment 7

[Tracy Walker [:tracy]]

Attachment: log of cancelled easy setup

I believe this is fixed, Not seeing 400's. However, please review the attached log of cancelled easy setup transaction.  Does that look correct?

Comment 8

[Tarek Ziadé (:tarek)]

(In reply to comment #7)
> Created attachment 528608 [details]
> log of cancelled easy setup
> d'
> I believe this is fixed, Not seeing 400's. However, please review the attached
> log of cancelled easy setup transaction.  Does that look correct?

I am not sure what gets logged here. Adding rnewman and philikon to the loop.

Also, maybe you can run the same test on the prod server and see if there's a diff. e.g. a 400.

Comment 9

[Philipp von Weitershausen [:philikon]]

(In reply to comment #7)
> I believe this is fixed, Not seeing 400's. However, please review the attached
> log of cancelled easy setup transaction.  Does that look correct?

Tracy, if you used yesterday's s-c build or today's nightly, then you have a fixed client. We fixed both the client and the server. To test whether just the server was fixed, please use an older s-c build or Aurora.

Comment 10

[Tracy Walker [:tracy]]

Attachment: aurora log oc easy setup ablort

Ok so the messaging is slightly different on aurora, but no 400's.

Comment 11

[Tracy Walker [:tracy]]

(In reply to comment #8)
> Also, maybe you can run the same test on the prod server and see if there's a
> diff. e.g. a 400.

Yep,  400 with aurora against production.  Not seeing such in stage. 

QA - PASS

Comment 12

[:Atoll]

This was previously scheduled for 2011-05-02 but we pushed forward a week to ensure QA presence for the 3pm deploy window, and is now scheduled for today 2011-05-09 at 3pm PST8PDT.

Comment 13

[:Atoll]

Upgraded wp-jpake01/02.phx in production PHX, Tracy is writing QA pass email.  This production deploy event is complete.  SCL2 standby servers (which are not in production) will be upgraded once Pete is available.

Comment 14

[:Atoll]

updated SCL2 standby servers using rpms build on adm2.scl2.svc.m.c