Closed Bug 650328 Opened 9 years ago Closed 9 years ago

Deploy KeyExchange server in stage then production

Categories

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

x86_64
Linux
task
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tarek, Assigned: Atoll)

References

Details

(Whiteboard: [qa+])

Attachments

(2 files)

Reassigning to Tarek to address the handoff checklist question from Mike.  Taking no action at this time.
Assignee: nobody → 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.
the changed functional test that tests this can be found in the changeset: https://hg.mozilla.org/services/server-key-exchange/rev/22cfba3c4aee
Assignee: tarek → rsoderberg
Status: NEW → ASSIGNED
Depends on: 653105
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.
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.
Assignee: rsoderberg → nobody
Status: ASSIGNED → NEW
Whiteboard: [needs QA]
I believe this is fixed, Not seeing 400's. However, please review the attached log of cancelled easy setup transaction.  Does that look correct?
(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.
(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.
Ok so the messaging is slightly different on aurora, but no 400's.
(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
Whiteboard: [needs QA]
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.
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.
Assignee: nobody → rsoderberg
Status: NEW → ASSIGNED
updated SCL2 standby servers using rpms build on adm2.scl2.svc.m.c
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Whiteboard: [qa+]
You need to log in before you can comment on or make changes to this bug.