1. OK, so you are quite defensive and rude about this for some reason
You are suggesting modifying and maintaining (currently) 5 migrate scripts,
then redistributing (and keeping up-to-date)
90 other scripts, just to cope with a current deficiency with the current
mechanism available for add-ons with regards to
hooking into the current infrastructure.
That was me being restrained.
>I know it's not as elegant as the four line solution but point 2.
To put it mildly.
I'm *not* trying to insist my solution is included, but there needs to be "a"
solution and generating lots more
duplicate code to install and redistribute simply isn't "it" and I'm more than
a little shocked anyone would suggest it!
--
Gareth Bult
“The odds of hitting your target go up dramatically when you aim at it.”
See the status of my current project at http://vdc-store.com
----- Original Message -----
From: "David Macleod" <[email protected]>
To: "Gareth Bult" <[email protected]>
Cc: "Jaime Melis" <[email protected]>, [email protected]
Sent: Monday, 20 January, 2014 12:50:14 PM
Subject: Re: [one-dev] Live migration / recovery - suggestions
1. OK, so you are quite defensive and rude about this for some reason.
2. The OpenNebula project has just said they don't want to change their
code base to suit you, so your four line solution is off the table.
3. You don't need to write the vmm drivers from scratch. Just copy the
three provided with ONE call them kvm-vdc, xen-vdc and vmware-vdc or something,
then make your customization to them. I know it's not as elegant as the four
line solution but point 2.
On Mon, Jan 20, 2014 at 2:23 PM, Gareth Bult < [email protected] > wrote:
Once I switch to a different vmm (say "vdc" rather than "kvm") , how will the
system know to fall back on
the hypervisor in use for all the other scripts that I don't want to modify?
--
Gareth Bult
“The odds of hitting your target go up dramatically when you aim at it.”
See the status of my current project at http://vdc-store.com
From: "David Macleod" < [email protected] >
To: "Gareth Bult" < [email protected] >
Cc: "Jaime Melis" < [email protected] >, [email protected]
Sent: Monday, 20 January, 2014 11:57:31 AM
Subject: Re: [one-dev] Live migration / recovery - suggestions
No, you should write a basic framework around the migrate script that supports
the three hypervisors that OpenNebula uses.
>>> Gareth Bult < [email protected] > 2014/01/20 02:15 PM >>>
Erm, yeah, Ok, should I include filters for the coffee machine too ?!
--
Gareth Bult
“The odds of hitting your target go up dramatically when you aim at it.”
See the status of my current project at http://vdc-store.com
From: "David Macleod" < [email protected] >
To: "Gareth Bult" < [email protected] >
Cc: "Jaime Melis" < [email protected] >, [email protected]
Sent: Monday, 20 January, 2014 11:50:26 AM
Subject: Re: [one-dev] Live migration / recovery - suggestions
Then distribute a vmm driver per hypervisor...
>>> Gareth Bult < [email protected] > 2014/01/20 02:01 PM >>>
.. Erm, because the vmm driver is per-hypervisor .. and this product is
technically
hypervisor agnostic .. ??
--
Gareth Bult
“The odds of hitting your target go up dramatically when you aim at it.”
See the status of my current project at http://vdc-store.com
From: "David Macleod" < [email protected] >
To: "Gareth Bult" < [email protected] >, "Jaime Melis" < [email protected]
>
Cc: [email protected]
Sent: Monday, 20 January, 2014 11:32:33 AM
Subject: Re: [one-dev] Live migration / recovery - suggestions
Hi Gareth, Jaime
Why can't the recovery be handled by the migrate script? You can distribute
your own custom vmm driver so that it doesn't get overwritten by the updates.
That's how I wrote my add-on, I also have the need to recover from a migrate
fail.
Regards,
David
>>> Jaime Melis < [email protected] > 2014/01/20 12:43 PM >>>
Hi Gareth,
we've been studying your proposal, and even though we agree with what you say
we
aren't 100% convinced with this solution. The issues with the proposal are the
following:
- As long as it's possible, we'd like to keep separate the main opennebula code
and the addons. In this case it means that we are not very comfortable with
point 3: adding addon-specific code to the main repository.
- The proposed solution only solves the "migrate" issue, but other addons will
have potentially issues with other scripts, and not necessarily with the
"CleanUp" part of the "ssh_exec_and_log". We would like to find a more general
solution.
We are still thinking about this, we definitely want to solve this issue, so if
you (or anyone else) has any ideas, please let us know.
cheers,
Jaime
On Tue, Jan 14, 2014 at 2:23 PM, Gareth Bult < [email protected] > wrote:
<blockquote>
Hey Guys, I've done a little work on the migration script - this is what I've
done here ..
- be nice if something similar could be implemented @ source .. ?
1. ssh_exec_and_log (generic change - this could be useful elsewhere..) modify
as follows;
function ssh_exec_and_log
{
message=$2
cleanup=$3 # ++
EXEC_LOG_ERR=`$1 2>&1 1>/dev/null`
EXEC_LOG_RC=$?
if [ $EXEC_LOG_RC -ne 0 ]; then
log_error "Command \"$1\" failed: $EXEC_LOG_ERR"
if [ ! -z $cleanup ]; then # ++
$cleanup # ++
fi # ++
if [ -n "$2" ]; then
error_message "$2"
else
error_message "Error executing $1: $EXEC_LOG_ERR"
fi
return $EXEC_LOG_RC
fi
}
i.e. allow a third parameter which is a function to call if the exec fails.
2. migrate (for my vdc code), add "CleanUp" as a last parameter on the
exec_and_log on the last line
ssh_exec_and_log "virsh --connect $LIBVIRT_URI migrate --live $deploy_id
$QEMU_PROTOCOL://$dest_host/system" \
"Could not migrate $deploy_id to $dest_host" CleanUp
3. Then add the following function to migrate;
function CleanUp
{
VDC=$(dirname $0)/../../../vdc-nebula
if [ -d "${VDC}" ]; then
${VDC}/remotes/tm/vdc/postmigrate_fail ${deploy_id} ${dest_host}
fi
}
Cleanup could be extended for other storage options ... ??
I guess ideally you would pass the driver through and CleanUp would become
completely generic and postmigrate_fail
would become just another standard routine??
</blockquote>
_______________________________________________
Dev mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org
