ESbox > Build Machines needs some improvements with regard to the steps a user must take to get the correct DHCP
address assigned to a virtual machine.  The user can't predict this address without starting the machine, but ESbox
complains and gets confused when you try to apply or validate settings on a machine which it can't contact.

Also, the validation information is still in dialog-only form, when it should be in a form more amenable to reviewing
later on.

 
From Arto:

First, I want to remind you about this "Sanity test passed!" information issue, it's still exists.

When you Validate Build Machines first time after configuration, Esbox don't show any error messages or "Sanity
tests passed!" information.
[[[ejs]]] Hmm... does anything happen at all?  Does the VM launch?  (Or are you using the manual mode?) 

[[[aoh]]] I using VMware Linux Build Machine and everything in validation went Ok. VM starts, Esbox asks password for
SMB shares, only "Sanity tests passed" note is missing when you run validation first time after configuration.

Are there any errors in other pages or fields when you press the button? 

[[[aoh]]] No.

If you rerun "Apply and Validate Machine" without any modification to Machine access settings, you get
information

-----

And second, the best way to validate build machine in Windows is:
 - start VM server manually
 - find valid ip address with ifconfig
 - start ESBox, configure build machine settings and validate machine twice to get "Sanity test passed" info.

If you let ESBox to start VM server, it goes something like this:
 - start ESBox - Windows - Preferences - ESBox - Build Machines - Machine access
 - select "Autoselect network settings"
 - target address is: 192.168.0.0
 - select "Apply and Validate Machine"
 - wait VM to start
 - select link "ESBox > Build Machines Preferences" from "Launching Virtual Machine" info
 - ESBox is still "Acquiring VMware Linux Build Machine" and and starts new VM instance
 - select "cancel"
 - wait ...
 - select link "ESBox > Build Machines Preferences" from "Launching Virtual Machine" info
 - edit valid Target address: 192.168.0.196
 - select "Apply and Validate Machine"
 - ESBox starts new VM instance select "cancel"
 - and if you are lucky, ESBox manages to validate build machine

Tested with
 - Windows XP
 - esbox_2.0.0-I200904220915
 - VMware Player 2.5.2 build-156735

Date: 2009-10-16 13:11
Sender: Arto Hyvarinen

Verified with Esbox_build.542 in Mac, Windows XP and Vista.

Date: 2009-09-21 13:03
Sender: Ed Swartz

Ok, I think this is fixed now.  

(1) Any launch of a VM must be approved manually.  We used to
launch any time we couldn't locate the machine's address.  But
now we distinguish whether a VM engine is running, or whether
we just can't see it, and present a "Launch?" dialog
vs. a "network problem" dialog depending.

Both dialogs share an expandable "Help>>" section
that references the common reasons for error if our diagnosis
was incorrect.

(2) The Build Machines page changes "Apply and Validate"
to "Validate" so the machine can be launched and tested
without affecting the rest of the system.

Removed some SDK refreshing that was unnecessary and could interfere
with configuring a machine, or run with the old machine's
settings.

(3) When we reference a VM, we provide more information (like
the target IP and/or the machine name) so it's easier for the
user to know which is being tested or going to be launched. 
(This can help debug cases like the one where we accidentally
launched the old machine.)

Date: 2009-09-14 16:40
Sender: Ed Swartz

Another issue related to this.  The Mica SDK refresh job is usually
the thing that triggers the launch of a VM, since this refresh
is needed to re-establish the list of available SDKs and targets
shortly after startup.

But the lazy initialization of targets has an unwanted side effect.
I wanted it to be automatic that you could start up a clean system,
with no VM running, and when first activating any Mica/ESbox
UI, then it would automagically launch the VM.

Unfortunately, this automatic startup can happen in undesirable
places, especially when configuring new machines, where the machine
settings are not fully established.  In several cases, a cached
SDK refresh job can start up using the *old* machine information,
or it can run with half-initialized data that is not even suitable
for launching the machine.  Thus, you end up with a few stacked
jobs which will all fail, long after the build machine is
configured.

The solution seems to be to make VM startup manual (at the very
least, approved by the user via a dialog).

In the Build Machine pref usage, should have explicit UI to test
the machine without "exposing" the machine to the rest
of the system and triggering SDK refreshes.

Or, there should be some marker or indication on a build machine
that it has been fully configured before trying to perform an
SDK refresh.

Date: 2009-09-03 15:29
Sender: Ed Swartz

There are some other issues caused by this one (Maemo SDK VM
installer issues which result in bad UI and hangs).

Probably we need to have a model where build machines are not
launched automatically until their configurations have been
proven.

Date: 2009-04-24 14:10
Sender: Ed Swartz

Also, validation for a brand-new VM or one without scratchbox
will not be very informative (we assume targets must be available,
and if not, we complain a lot).