Please deploy Loop-Client 0.7.0 code to stage

VERIFIED FIXED

Status

Cloud Services
Operations: Deployment Requests
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: standard8, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
We'd like to deploy the loop-client 0.7.0 release to stage.

https://github.com/mozilla/loop-client/releases/tag/0.7.0

This can be done whenever, though it'd be good to get it out soon, as there are some UX improvements.

CONFIG CHANGES:

config/config.js needs some additional variables, the variables are:

-- loop.config.fxosApp
-- loop.config.fxosApp.name
-- loop.config.fxosApp.manifestUrl

I do not yet know the values of these.

:ferjm please can you advise what these should be for our staging environment
Flags: needinfo?(ferjmoreno)
(Reporter)

Updated

3 years ago
Blocks: 1077061
The manifest URL is only available after uploading the app to the Market Place, and we are blocked as the MP team has not advised us about how to publish the app in a restricted mode.
Flags: needinfo?(ferjmoreno)
Tarek -- Can you get this and bug 1077061 prioritized with the Ops team for deployment?  Maria/TEF needs this deployed ASAP.  Thanks!
Flags: needinfo?(tarek)
(In reply to Mark Banner (:standard8) from comment #0)
> We'd like to deploy the loop-client 0.7.0 release to stage.
> 
> https://github.com/mozilla/loop-client/releases/tag/0.7.0
> 
> This can be done whenever, though it'd be good to get it out soon, as there
> are some UX improvements.
> 
> CONFIG CHANGES:
> 
> config/config.js needs some additional variables, the variables are:
> 
> -- loop.config.fxosApp
> -- loop.config.fxosApp.name
> -- loop.config.fxosApp.manifestUrl
> 
> I do not yet know the values of these.
> 
> :ferjm please can you advise what these should be for our staging environment

Maria, Fernando -- Do you know the answer to Mark's question? We need this answered in order to deploy. Thank you!
Flags: needinfo?(oteo)
I wrote my previous response too quickly: 

Maria/Fernando -- can you provide loop.config.fxosApp and loop.config.fxosApp.name?

And for the third question:  loop.config.fxosApp.manifestUrl will come after you publish to the MP -- which is blocked on MP telling you how to do it? Am I correct?

Tarek -- we may be truly blocked here without the manifestUrl, but can we at least give the Ops folks a heads up that we'll need this deployed as soon as we have the information?

Can we deploy with everything except the manifestUrl and then update it as soon as we have it -- or can we not do any of this deployment without it?  I'm trying to save as much time as possible in getting this out-the-door .  (I think this is question for everyone to think about.  If we do want to try this, we'll definitely need to test it.)  Thanks.

Also, adding Shell to this discussion.
Flags: needinfo?(sescalante)

Comment 5

3 years ago
We can deploy everything (code and config) apart from that setting and value if we're sure the application in staging will function gracefully without it. If that config being missing breaks the applicaiton then we'll have to hold the release until it's ready
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #4)
> I wrote my previous response too quickly: 
> 
> Maria/Fernando -- can you provide loop.config.fxosApp and
> loop.config.fxosApp.name?
> 

We could say that it is "Firefox Hello" but it is useless without the manifestUrl, so I would rather wait until we have both values.

> And for the third question:  loop.config.fxosApp.manifestUrl will come after
> you publish to the MP -- which is blocked on MP telling you how to do it? Am
> I correct?
> 

Yes, this is blocked by the MP publication.

> Tarek -- we may be truly blocked here without the manifestUrl, but can we at
> least give the Ops folks a heads up that we'll need this deployed as soon as
> we have the information?
> 
> Can we deploy with everything except the manifestUrl and then update it as
> soon as we have it -- or can we not do any of this deployment without it? 

We can safely deploy without any of the FxOS config options. These config options are only used when the standalone UI is running on FxOS so it won't affect its normal behavior in any other platform.

Once we have published the app in the MP, we can add the corresponding config bits so we can test the standalone on FxOS as well.
Flags: needinfo?(oteo)

Comment 7

3 years ago
I've deployed the loop-client 0.7.0 code to staging, without any config changes or additions.
VERIFIED HOST RUNNING FOLLOWING RELEASE:

puppet-config-loop 20141003092304-1 x86_64 15582
loop-client-svcops 0.7.0-1 x86_64 11784080


/data/loop-client/content/VERSION.txt:
0.7.0
22d17d885245f6626e460b5e67a243e2db042401 Thu, 2 Oct 2014 20:20:50 +0100


FILES ON STAGE:
/opt
aws  ec2  openresty  rh  stackdriver

/data:
hekad  loop-client

/etc:
heka.d

/etc/puppet/yaml/app:
loop_client.dev.yaml  
loop_client.prod.yaml 
loop_client.stage.yaml  
loop_client.yaml  
loop_server.dev.yaml  
loop_server.prod.yaml  
loop_server.stage.yaml  
loop_server.yaml

LOGS:
/var/log/circus.log
/var/log/hekad
/media/ephemeral0/nginx/logs 

HEKA
/data/hekad
/etc/heka.d

PROCESSES:
stackdriver, nginx, python, circus, heka 

QUICK CHECKS:

https://call.stage.mozaws.net/VERSION.txt:
0.7.0
22d17d885245f6626e460b5e67a243e2db042401 Thu, 2 Oct 2014 20:20:50 +0100


$ curl -I https://call.stage.mozaws.net:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-length: 2523
Content-Type: text/html
Date: Mon, 06 Oct 2014 16:38:22 GMT
ETag: "542eaf36-9db"
Last-Modified: Fri, 03 Oct 2014 14:14:14 GMT
Vary: Accept-Encoding
Connection: keep-alive


config.js correct for STAGE:
/data/loop-client/content/config.js
var loop = loop || {};

loop.config = {
  serverUrl: 'https://loop.stage.mozaws.net',
  feedbackApiUrl: 'https://input.allizom.org/api/v1/feedback',
  feedbackProductName: 'Loop'
};



https://call.stage.mozaws.net/config.js:
var loop = loop || {};

loop.config = {
  serverUrl: 'https://loop.stage.mozaws.net',
  feedbackApiUrl: 'https://input.allizom.org/api/v1/feedback',
  feedbackProductName: 'Loop'
};


https://call.stage.mozaws.net/:
Welcome to the WebRTC! web client.


https://loop.stage.mozaws.net/:
{"name":"mozilla-loop-server","description":"The Mozilla Loop (WebRTC App) server","version":"0.12.3","homepage":"https://github.com/mozilla-services/loop-server/","endpoint":"https://loop.stage.mozaws.net","fakeTokBox":false,"fxaOAuth":true,"i18n":{"defaultLang":"en-US","lang":"en-US"}}


PUPPET FILES:

/etc/puppet/yaml/app/loop_client.stage.yaml:

loop_client::app_server_url: "https://loop.stage.mozaws.net"
loop_client::feedback_api_url: "https://input.allizom.org/api/v1/feedback"


/etc/puppet/yaml/app/loop_client.yaml:

classes_hash:
    loop_client: true
    stackdriver: true

stackdriver::nginx::nginx_status_url: http://127.0.0.1:7999/nginx_status

loop_client::app_server_url: "SET_ME"


https://call.stage.mozaws.net/legal/terms/ - VERIFIED
testing is done for STAGE with current deployment.  

Comment #5 (deanw):
> We can deploy everything (code and config) apart from that setting and value if we're 
> sure the application in staging will function gracefully without it. If that config
> being missing breaks the applicaiton then we'll have to hold the release until it's ready

Comment #6 (ferjm):
> We can safely deploy without any of the FxOS config options. These config options are only 
> used when the standalone UI is running on FxOS so it won't affect its normal behavior in 
> any other platform.
> Once we have published the app in the MP, we can add the corresponding config bits so we 
> can test the standalone on FxOS as well.

Maire, is Ops good to go or do we need to retest on stage with some different options before proceeding?
Dmose just verified for me that Loop Desktop works with what's on loop.stage.   He was having problems with loop-dev.stage (see Bug 1078668), but I believe loop-dev.stage implements Rooms (brand new software that isn't in release yet).

Before we move this to production, I'd like us to verify that the Loop mobile app works properly against loop.stage.  Fernando -- can you point to https://loop.stage.mozaws.net to see if calls works for you and if this unblocks your testing?   If it looks good, we can push this to production.
Flags: needinfo?(ferjmoreno)
Massimo will take care of the testing against stage.
Flags: needinfo?(ferjmoreno) → needinfo?(mbarone976)

Updated

3 years ago
Flags: needinfo?(tarek)

Comment 12

3 years ago
Hi 

Performed a quick smoke test. There is a delay in the audio (but we've seen this also in production). The problem that I've seen is that is not possible to have a call between Desktop and mobile app. The call is not established. The rest of the tests are pass.

Test executed: 
- Login/Logout with FxA (from settings, from the app)
- Login/Logout with Mobile ID (detected by the app, introduced manually)
- Video/Audio calls from Contact app and from the call log
- Activate/Deactivate video, micro (with the speaker there is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1076756)
- Reject the call
- Receive/Make a call from/to Desktop - FAIL
(Reporter)

Comment 13

3 years ago
(In reply to mbarone from comment #12)
> Performed a quick smoke test. There is a delay in the audio (but we've seen
> this also in production). The problem that I've seen is that is not possible
> to have a call between Desktop and mobile app. The call is not established.

How are you making the call? Are you providing a link to the desktop application, or are you trying to do it via contacts?

Direct calling via contacts is only just implemented in the latest nightly and has nothing to do with this deployment.

This deployment only affects the link-clicker environment.

Comment 14

3 years ago
Scenario A: Mobile A logged with FxA1 and Desktop logged with FxA2. The FxA1 calls (from contact detail) to the FxA2, but the fallback mechanism is shown. So, it seems that the other party is not logged into FxA.

Scenario B: Desktop logged with Fx2 and call FxA1 via contacts. The desktop try to establish the call, but a warning message is shown informing to retry.
Flags: needinfo?(mbarone976)
(Reporter)

Comment 15

3 years ago
(In reply to mbarone from comment #14)
> Scenario A: Mobile A logged with FxA1 and Desktop logged with FxA2. The FxA1
> calls (from contact detail) to the FxA2, but the fallback mechanism is
> shown. So, it seems that the other party is not logged into FxA.
> 
> Scenario B: Desktop logged with Fx2 and call FxA1 via contacts. The desktop
> try to establish the call, but a warning message is shown informing to retry.

This scenarios both don't involve the link-clicker UI. As such, they would not be affected by the deployment of loop-client which is only involving the link-clicker UI.

However, to get your scenarios to work, I suspect you'll need to change the "loop.server" preference on desktop to be "https://loop.stage.mozaws.net" (and then restart & re-login).
(Reporter)

Comment 16

3 years ago
To clarify where I think we are:

1) For me, clicking a link on desktop using this stage works fine.
2) When I tried using a link on the standalone:
2a) Without FxOS Loop client installed, clicking start doesn't do anything (due to the config settings).
2b) With FxOS Loop client installed, it seemed to pass the data to the Loop client. It didn't start the call, but that's because I hadn't configured the Loop client for staging.

If we are fine with how this is working, then I think we can move forward.

If we're not find with 2a, then I think we'll have to do an additional (small) patch to make it start a call if the config setting is not present.
Flags: needinfo?(sescalante)
Flags: needinfo?(mreavy)
Flags: needinfo?(mbarone976)
Regarding 2a: If a FxOS user clicks on a link in the browser, we want it to start the call.  So we should create and land the patch to start a call if the config setting is not present.
Flags: needinfo?(mreavy)
(Reporter)

Updated

3 years ago
Depends on: 1079955
(Reporter)

Comment 18

3 years ago
I filed bug 1079955 to fix the FxOS case without the marketplace settings.
Flags: needinfo?(mbarone976)
(Reporter)

Comment 19

3 years ago
I've discussed this more with mreavy over irc. We've decided the work to fix bug 1079955 isn't going to be worth it, and we'll move forward, despite the issue for FxOS users that haven't got the client installed, as this allows some testing to go on.

Obviously we'll want to get the app in the marketplace as soon as possible, and the config updated, and we'll do that when we can.

Hence marking this as fixed, as it is already deployed per comment 7, and no further changes to the config are required.
Blocks: 1079955
Status: NEW → RESOLVED
Last Resolved: 3 years ago
No longer depends on: 1079955
Resolution: --- → FIXED
Mark is correct.  And given the new behavior that FxOS Loop wants: to complete the call on FxOS with the Loop app if it is installed or go to the marketplace if the app is not installed, any temporary workaround we create would not be useful to the tests that TEF wants to do.  It would be totally wasted work.  

In fact deploying this now should actually enable TEF to test their scenarios sooner -- such that their testing is only blocked on the MP deployment.
Hey Dean - 
spoke with mreavy today and they're ready to go to prod with this.  
Let me know when you do and I'll verify.  -Thanks!
Flags: needinfo?(dwilson)

Updated

3 years ago
Flags: needinfo?(dwilson)
Status: RESOLVED → VERIFIED
Spoke with deanw and bobm this morning.  Re-opening stage ticket to validate a secondary instance of 0.7.0 for (loop-client app server (loop-client-2014-10-10-16-03).  
Per deanw, this is a copy of loop-client-app instance needed for Bug 1081086.  Will do some quick checks to verify.
[10:18] deanw: rpapa: and bobm elbs in stage are - 
          loop-clien-CallELB-XUZKGEHUJRJO-846910481.us-east-1.elb.amazonaws.com - 
          loop-clie-HelloELB-DC612LYQQARQ-439661508.us-east-1.elb.amazonaws.com
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
------------------------------
VERIFIED *ADDITIONAL* HOST RELEASE VERSION
host: loop-client-2014-10-10-16-03

loop-client-svcops 0.7.0-1 x86_64 11784080
puppet-config-loop 20141009174905-1 x86_64 15667

/data/loop-client/content/VERSION.txt:
0.7.0
22d17d885245f6626e460b5e67a243e2db042401 Thu, 2 Oct 2014 20:20:50 +0100


FILES ON STAGE:
/opt
aws  ec2  openresty  rh  stackdriver

/data:
hekad  loop-client

/etc:
heka.d

/etc/puppet/yaml/app:
loop_client.dev.yaml  
loop_client.prod.yaml 
loop_client.stage.yaml  
loop_client.yaml  
loop_server.dev.yaml  
loop_server.prod.yaml  
loop_server.stage.yaml  
loop_server.yaml

LOGS:
/var/log/circus.log
/var/log/hekad
/media/ephemeral0/nginx/logs 

HEKA
/data/hekad
/etc/heka.d

PROCESSES:
stackdriver, nginx, python, circus, heka 


QUICK CHECKS

https://call.stage.mozaws.net/VERSION.txt:
0.7.0
22d17d885245f6626e460b5e67a243e2db042401 Thu, 2 Oct 2014 20:20:50 +0100


https://call.stage.mozaws.net/config.js

var loop = loop || {};

loop.config = {
  serverUrl: 'https://loop.stage.mozaws.net',
  feedbackApiUrl: 'https://input.allizom.org/api/v1/feedback',
  feedbackProductName: 'Loop'
};

https://call.stage.mozaws.net/:
Welcome to the WebRTC! web client.

NOTE:
loop-server STAGE currently at release 0.12.4 (not yet tested) 


https://loop.stage.mozaws.net/:
{"name":"mozilla-loop-server","description":"The Mozilla Loop (WebRTC App) server","version":"0.12.4","homepage":"https://github.com/mozilla-services/loop-server/","endpoint":"https://loop.stage.mozaws.net","fakeTokBox":false,"fxaOAuth":true,"i18n":{"defaultLang":"en-US","lang":"en-US"}}
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.