Hi Joe,
Almost everything looks good. I have one more comment on the issue
below, however.
>>
>> 295-300: We blindly destroy an existing VM? Will first time users
>> blow away their VMs when they give their VMC build name the same name
>> as a current VM? Should we be using the --basefolder flag to create
>> the VM in the DC build area instead of $HOME/.VirtualBox? (Especially
>> since we're running as root to fire off DC...). If we did this, we
>> might be able to handle my previous comment by unregistering an
>> existing VM if it's not located in the DC build area (and of course,
>> re-registering it when finished).
>
> Yes agreed. We investigated using --basefolder but did not have the
> full success. We wanted to move forward and felt the likelihood of a
> user being negatively impacted was small. We will use --basefolder in
> phase II.
>
How will this behavior be documented? I think it's important to inform
the user of this behavior and how to restore it. In this specific
scenario, we could safely just delete the VM, but leave the virtual
disks intact, which would mean that we're not destroying any data that
can't be recovered (it's easy enough to recreate a VM and re-register
the hard disks). Could you modify 'cleanup' to do so (or split it out to
functions that destroy the VM and destroy the hard disks)?
This would be additionally beneficial, as the cleanup code makes
assumptions about the VM that are directly tied to how VMC creates the
VM, not how a user might have set it up - for example, if a user has a
VM named ${DIST_NAME} with multiple attached hard disks, cleanup will
fail to destroy the VM (which means VMC will fail).
Thanks,
Keith
