On 06/29/2011 07:08 PM, Chris Lumens wrote:
On machines with hundreds of devices Anaconda looks dead during device
discovery. Having a proper progress bar would be cooler but we don't know
how many devices will be there altogether.
How much does the progress indicator bounce back and forth? Is it
really crazy, or fairly controlled?
You can say it's controlled. On a Dell server it is pretty smooth, on
virt it is jumping a bit in the beginning.
For master, I suggest making progressWindow=None the default and
adapting the rest of the patch to that. Remember that we can import
storage as a library elsewhere, and we won't always want to pass in an
interface component. I'm thinking of anaconda-cleanup and the storage
test code here.
This is interesting point and and I agree. It is also related to the
discussion there was last night on IRC about having to pass around the
anaconda instance, though I wouldn't like to sound like I am suggesting
the same solution there. I tried to address the interface problem in my
multithreading UI experiments [1] and the best approach seemed to be
having a singleton object ('status', because I like to think of it as
something the control code announces, like a twitter message, without
caring whether someone consumes it) that is always obtainable via a
method. The storage code talks to this object as 'indicate progress' or
'display a warning', and does not really care if and when the UI carries
those requests out. The status object doesn't need to be passed around
at all, the methods that like to present something to the UI can request
it at any time. Before any InstallInterface object is instantiated
status silently ignores all the requests. Once the interface exists, the
status object is updated and starts processing those requests properly
(in the multithreading case that also meant asynchronously in general).
The benefits are no more passing the interface around and checking it
against None.
One issue remains: sometimes you need to hear back from the UI, like
'reinitialize disk vda?'. By default I think this situation should raise
an exception if proper interface does not exist yet for the behavior is
undefined. In tests this is easy to workaround by supplying a mock object.
Ales
[1] https://github.com/akozumpl/anaconda/commits/multi
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
