Merge lp://staging/~vila/ols-store-tests/redirection-failures into lp://staging/~ubuntuone-pqm-team/ols-store-tests/store-acceptance-tests

<pindonga> vila, mhh
<pindonga> I mean... that means that the current staging server and tests only work inside the datacenter?
<pindonga> afaik .internal is not resolvable outside the internal network
<pindonga> not even sure if via vpn
<vila> pindonga: hmm, no, the tests work from outside
<vila> pindonga: what doesn't work (from inside the vpn) is to attempt to use .internal because it's self-signed so ssl barfs
<pindonga> ah, it works bc it only shows you the url in the data
<pindonga> it doesn't try to actually go to that url
<pindonga> that would fail
<vila> pindonga: the tests (as they are written right now), requires that the url in the response is myapps. yeah that
<vila> yes
<pindonga> do you know why we redirect to an internal url?
<pindonga> is it bc we don't yet have a dns name defined?
<vila> because the domain is still unknown
<vila> yes
<pindonga> k
<pindonga> I guess it's ok for now
<pindonga> though I'm not that satisfied (with the overall redirect approach) I'll +1 this mp
<vila> so the tests will fail again once we have that domain, but I prefer that over... yeah

FWIW, the tests aren't restricted to the datacenter - as they don't involve needing to browse the new domain. All that's being checked here is the returned URL - which since it's being processed (via proxy) on the new deployment, uses the new domain.

We now have a domain and are updating staging to use dashboard.staging.snapcraft.io, but you'll still have the issue that you're hitting myapps.developer.staging.ubuntu.com here, but the response is being served by dashboard.staging.snapcraft.io - as will the returned URL - which is correct.

At a later date, we can update these tests to run against dashboard.staging.., but right now I think they should continue to run against myapps.developer.staging and expect the api response to direct people to the new url.

> At a later date, we can update these tests to run against dashboard.staging.., but right now I think they should continue to run against myapps.developer.staging and expect the api response to direct people to the new url.

Why not using the new domain right now ? (I have a branch where I just check dashboard.staging.snapcraft.io instead of scasnap.ols.staging.internal and they pass).

I'm doing a run with SCA_ROOT_URL pointed at the new domain.... and it passes.

Discussing with Shawn and Kelvin though, the consensus is to keep pointing at myapps.developer.staging so the tests can be used as a safety net for the redirection work.

See https://code.launchpad.net/~vila/ols-store-tests/new-dashboard-doamin/+merge/321039