Bug 975193 - geolocation works haphazardly
geolocation works haphazardly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Kolman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-17 14:56 EDT by Kamil Páral
Modified: 2014-04-17 09:49 EDT (History)
8 users (show)

See Also:
Fixed In Version: 20.2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-17 09:49:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log (4.79 KB, text/plain)
2013-06-17 15:03 EDT, Kamil Páral
no flags Details
program.log (56.93 KB, text/plain)
2013-06-17 15:03 EDT, Kamil Páral
no flags Details
journal (249.39 KB, text/plain)
2013-06-17 15:03 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2013-06-17 14:56:17 EDT
Description of problem:
This is a problem found in bug 975159. If I boot F19 TC3 Live and start Anaconda, sometimes I get Czech language pre-selected, but usually I get English language pre-selected. If I quit Anaconda and start it again, I get Czech pre-selected. I'm located in a Czech network.

I guess the geolocation requests are taking some time and Anaconda doesn't wait for the reply, so sometimes it works and sometimes it doesn't? But I have no idea why it always work if I run Anaconda for the second time in the same session.

Version-Release number of selected component (if applicable):
anaconda 19.30.5

How reproducible:
always, but hard

Steps to Reproduce:
1. Connect from a network that is detected as in Czech Republic (that is not Red Hat's Brno office, by the way).
2. Boot Live and run Anaconda
3. If English is pre-selected, quit Anaconda and run it again. Czech should be pre-selected now.

Actual results:
the location detection usually fails to detect user's location

Expected results:
the location detection doesn't seem random and works the same in most cases
Comment 1 Kamil Páral 2013-06-17 15:03:09 EDT
Attaching logs. I ran Anaconda (it detected English), quit it. Then run Anaconda again (it detected Czech), and quit it.
Comment 2 Kamil Páral 2013-06-17 15:03:29 EDT
Created attachment 762159 [details]
anaconda.log
Comment 3 Kamil Páral 2013-06-17 15:03:35 EDT
Created attachment 762160 [details]
program.log
Comment 4 Kamil Páral 2013-06-17 15:03:42 EDT
Created attachment 762161 [details]
journal
Comment 5 Martin Kolman 2013-06-28 10:44:53 EDT
Yeah, there is currently sort of race between the GUI showing up and GeoIP lookup finishing. On non-live installs, quite a lot of stuff needs to be started (such as for example X and loading GTK to memory), so the lookup has more time to finish before the GUI shows up.

On the other hand, on live installs, most stuff is already loaded and the Anaconda interface shows up very quickly. So it can easily happen, that that lookup, that usually takes up about 1-2 seconds finishes after the GUI is already shown.

I've just submitted a patch for review, that makes anaconda wait for up to 3 seconds for the GeoIP lookup to finish, before showing the GUI. This should make geolocation on live installs work more consistently, at the cost of making the Anaconda interface startup longer by about a second (and in worst case by 3 seconds).
Comment 6 Martin Kolman 2013-07-11 05:21:17 EDT
So a fix has been pushed and should be part of the next version (20.2-1). It wait for up to 3 seconds for Geolocation to finish - so please test and report in case that the timeout is too short.
Comment 7 Steve Tyler 2013-07-11 09:27:55 EDT
For the record, could you post how you chose 3 seconds?
Comment 8 Martin Kolman 2013-07-15 11:17:19 EDT
(In reply to Steve Tyler from comment #7)
> For the record, could you post how you chose 3 seconds?

It seems that all GeoIP queries I've done so far take between 1 and 2 seconds, so I've used the worst case and added a 50% margin. 
But I take the 3 seconds as an initial guess, if anyone finds that it is too short in some scenario, it can be changed.
Comment 9 Steve Tyler 2013-07-15 13:51:38 EDT
(In reply to Martin Kolman from comment #8)
> (In reply to Steve Tyler from comment #7)
> > For the record, could you post how you chose 3 seconds?
> 
> It seems that all GeoIP queries I've done so far take between 1 and 2
> seconds, so I've used the worst case and added a 50% margin. 
> But I take the 3 seconds as an initial guess, if anyone finds that it is too
> short in some scenario, it can be changed.

Thanks, Martin. If the GeoIP server gets busy, so that the reply takes longer than 3 seconds, is there a way to trigger a refresh?
(Without restarting the installer ...)
Comment 10 Kamil Páral 2013-07-16 04:17:41 EDT
I have to say the developer choice is very hard here. On the initial screen you can display some button to re-trigger to geo check and update the language when the GeoIP server is slow to respond, but 1) the language list is already visible 2) the button will be described in an incorrect language anyway. So it's a question whether the new button brings anything useful other then cluttering the screen.

I think Martin followed the best approach here - wait for a reasonable timeout, and if we don't receive a reply, just display the language selector. In that phase, the user can pick the language manually and a button to re-trigger geo lookup would bring hardly any benefits.
Comment 11 Martin Kolman 2013-07-16 04:18:53 EDT
(In reply to Steve Tyler from comment #9)
> (In reply to Martin Kolman from comment #8)
> > (In reply to Steve Tyler from comment #7)
> > > For the record, could you post how you chose 3 seconds?
> > 
> > It seems that all GeoIP queries I've done so far take between 1 and 2
> > seconds, so I've used the worst case and added a 50% margin. 
> > But I take the 3 seconds as an initial guess, if anyone finds that it is too
> > short in some scenario, it can be changed.
> 
> Thanks, Martin. If the GeoIP server gets busy, so that the reply takes
> longer than 3 seconds, is there a way to trigger a refresh?
> (Without restarting the installer ...)

No, way to refresh at the moment & not really planed because of how GeoIP is supposed to work:
* fully automatically
* only preset values and don't skip them
* don't change any settings that the user has already changed or even seen
So once the Welcome spoke is visible, user can just select the correct language by himself, not much point in using GeoIP at that point. Even a "refresh geoip" button would be IMHO kinda pointless as the user knows what language he wants and can just select it outright.

BTW, even if the GeoIP language preset times out, the actual GeoIP lookup is still running in the background and if it finishes before the user clicks "done" on the Welcome spoke, the result will be used to at least preset the timezone.
Comment 12 Steve Tyler 2013-07-16 10:09:54 EDT
Thanks, Kamil and Martin, that's very helpful.

I wasn't thinking of a geoip refresh button, but a user action from the existing GUI that would trigger a geoip refresh ...

From a wireshark capture, it appears that the installer connects to:
geoip.fedoraproject.org.
Is the geoip server configurable?
This would be useful for stress testing and fault injection.

I don't see any such option in the documentation:

Snippet from anaconda-19.30.13-1/docs/boot-options.txt:
...
=== inst.geoloc ===
Configure geolocation usage in Anaconda. Geolocation is used to pre-set
language and time zone.
`inst.geoloc=0`:: Disables geolocation.
`inst.geoloc=provider_fedora_geoip`:: Use the Fedora GeoIP API (default).
`inst.geoloc=provider_hostip`:: Use the Hostip.info GeoIP API.
...
Comment 13 Martin Kolman 2014-04-17 09:49:18 EDT
Has been implemented/fixed in the Fedora 20 time-frame, so closing. Please open new RFE bugs for any improvement ideas, such as those discussed in comments 7-12.

Note You need to log in before you can comment on or make changes to this bug.