Closed Bug 1033407 Opened 5 years ago Closed 5 years ago

Set MobileID service production URL

Categories

(Firefox OS Graveyard :: Runtime, defect)

defect
Not set

Tracking

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: ferjm, Assigned: ferjm)

References

Details

(Whiteboard: [qa+] ft:loop)

Attachments

(1 file)

We need to change the MSISDN server url once the production url mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1020899#c29 is working.
Component: DOM: Device Interfaces → General
Product: Core → Firefox OS
Depends on: 1020899
Whiteboard: [qa+]
Right now using the development server URL but for sure we need to change it to the Production one for 2.0,  so nominating.
blocking-b2g: --- → 2.0?
Whiteboard: [qa+] → [qa+] ft:loop
(In reply to Maria Angeles Oteo (:oteo) from comment #1)
> Right now using the development server URL but for sure we need to change it
> to the Production one for 2.0,  so nominating.

Will discuss in triage, but I'm leaning on the side of this being set with the feature-b2g flag, since this falls under required feature work for Loop.
Component: General → Runtime
(In reply to Jason Smith [:jsmith] from comment #2)
> (In reply to Maria Angeles Oteo (:oteo) from comment #1)
> > Right now using the development server URL but for sure we need to change it
> > to the Production one for 2.0,  so nominating.
> 
> Will discuss in triage, but I'm leaning on the side of this being set with
> the feature-b2g flag, since this falls under required feature work for Loop.

Its a semantic issue and not a big change to get into an argument on feature vs blocking, so I am going to block on this issue so we do not ship with this.
blocking-b2g: 2.0? → 2.0+
Maria -- Is this a change your team can make when the production url is ready?  Can someone on your team own this bug?  Thanks.
Flags: needinfo?(oteo)
Assignee: nobody → ferjmoreno
Thank you Fernando!
Flags: needinfo?(oteo)
just checking if this change has been checked in and uplifted?
Flags: needinfo?(ferjmoreno)
Hi Fernando -- I realize this is a simple change, but our release drivers want to get this in and uplifted ASAP.  Do you think you can do this tomorrow (Tuesday)?   Thanks!
AFAIK, the production server isn't ready yet. If I am not wrong, the push date is this Wednesday (15th), so we should not make the change until then.
Flags: needinfo?(ferjmoreno)
Attached patch v1Splinter Review
Attachment #8455949 - Flags: review?(fabrice)
Tarek, could you let us know when the production server is ready, so we can land this patch, please? Thanks :)
Flags: needinfo?(tarek)
The server is deployed but can only validates US number at the moment.
:shell can you tell us what country should be covered by the production MSISDN server?

At the moment the development server covers US/FR/SP and default to UK for international validation (with high cost for the end user.)
Flags: needinfo?(tarek) → needinfo?(sescalante)
Depends on: 1036736
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #10)
> Tarek, could you let us know when the production server is ready, so we can
> land this patch, please? Thanks :)

The production deployment is being handled by our ops see bug 1036736 (added in the blockers) right after the current tag has been validated and deployed on stage. This should be ready early this week.

The country numbers validation setup can be handled in parallel of switching to the production server. Worst case scenario will be to have the same set up as the dev server wrt phone #s.
((In reply to Tarek Ziadé (:tarek) from comment #12)
> Worst case scenario will be to have the same set up as the dev server wrt phone #s.

(Until we've tweaked them of course. But that can happen after the switch.)
No longer depends on: 1036736
Depends on: 1036736
(In reply to Tarek Ziadé (:tarek) from comment #12)
> (In reply to Fernando Jiménez Moreno [:ferjm] from comment #10)
> > Tarek, could you let us know when the production server is ready, so we can
> > land this patch, please? Thanks :)
> 
> The production deployment is being handled by our ops see bug 1036736 (added
> in the blockers) right after the current tag has been validated and deployed
> on stage. This should be ready early this week.

Tarek -- If this should be ready early this week, can we target landing this patch tomorrow (Wednesday)?   Sorry for the extra pressure, but our drivers are pushing us to land all blockers against v2.0 ASAP.  Thanks.
Flags: needinfo?(tarek)
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #14)
> 
> Tarek -- If this should be ready early this week, can we target landing this
> patch tomorrow (Wednesday)?  

I will be able to confirm this when Benson gets online today. He's pacific time.

> Sorry for the extra pressure, but our drivers
> are pushing us to land all blockers against v2.0 ASAP.  Thanks.

no problem at all !
Flags: needinfo?(tarek)
Production is live with the latest release: 0.3.1.
You can move forward with this change.
Status: NEW → ASSIGNED
Attachment #8455949 - Flags: review?(fabrice) → review+
Thanks!

I'll push it as soon as b2g-inbound or mozilla-inbound are open again (https://treestatus.mozilla.org/)
https://hg.mozilla.org/mozilla-central/rev/a5070fdf5801
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S6 (18july)
maire provided the info
Flags: needinfo?(sescalante)
You need to log in before you can comment on or make changes to this bug.