Bug 975193

Summary: geolocation works haphazardly
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: anacondaAssignee: Martin Kolman <mkolman>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, dshea, g.kaviyarasu, jonathan, mkolman, sbueno, stephent98, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 20.2-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-17 13:49:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
anaconda.log
none
program.log
none
journal none

Description Kamil Páral 2013-06-17 18:56:17 UTC
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 19:03:09 UTC
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 19:03:29 UTC
Created attachment 762159 [details]
anaconda.log

Comment 3 Kamil Páral 2013-06-17 19:03:35 UTC
Created attachment 762160 [details]
program.log

Comment 4 Kamil Páral 2013-06-17 19:03:42 UTC
Created attachment 762161 [details]
journal

Comment 5 Martin Kolman 2013-06-28 14:44:53 UTC
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 09:21:17 UTC
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 13:27:55 UTC
For the record, could you post how you chose 3 seconds?

Comment 8 Martin Kolman 2013-07-15 15:17:19 UTC
(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 17:51:38 UTC
(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 08:17:41 UTC
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 08:18:53 UTC
(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 14:09:54 UTC
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 13:49:18 UTC
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.