* Guido Trotter <[email protected]> [2014-02-28 12:53:13 +0100]: > On Wed, Feb 26, 2014 at 12:59 PM, Constantinos Venetsanopoulos > <[email protected]> wrote: > > Hello, > > > > So, shall we send an updated doc incorporating your comments > > to proceed? > > > > Yes, thanks, this sounds perfect. > > Guido
Hello, This is an interdiff that includes all things mentioned in the thread. Thanks, dimara diff --git a/doc/design-ifdown.rst b/doc/design-ifdown.rst index 839cf8b..7626da9 100644 --- a/doc/design-ifdown.rst +++ b/doc/design-ifdown.rst @@ -69,6 +69,15 @@ the `kvm-ifdown` script executes that script, as happens with `kvm-ifup`. Along with that change we should rename custom ifup script from `kvm-vif-bridge` (which does not make any sense) to `kvm-ifup-custom`. +In contrary to `kvm-ifup`, one cannot rely on `kvm-ifdown` script to be +called. A node might die just after a successful migration or after an +instance shutdown. In that case, all "undo" operations will not be invoked. +Thus, this script should work "on a best effort basis" and the network +should not rely on the script being called or being successful. Additionally +it should modify *only* the node local dynamic configs (routes, arp entries, +SDN, firewalls, etc.), whereas static ones (DNS, DHCP, etc.) should be modified +via hooks. + Implementation Details ====================== @@ -90,9 +99,9 @@ Currently TAP names are kept under This is not enough. As told above a NIC's index might change during instance's life. An example will make things clear: -* I start an instance with three NICs. -* I remove the second without hotplug -* I remove the first with hotplug. +* The admin starts an instance with three NICs. +* The admin removes the second without hotplug. +* The admin removes the first with hotplug. The index that will arrive with the RPC will be 1 and if we read the relevant NIC file we will get the tap of the NIC that has been removed on second @@ -109,7 +118,9 @@ The ifdown script should be aware of this corner case. Upon NIC hot-remove we obviously want to wipe everything. But on instance migration we don't want to reset external configuration like DNS. So we choose to pass an extra positional argument to the ifdown script (it already has the -TAP name) that will reflect the context it was invoked with. +TAP name) that will reflect the context it was invoked with. Please note that +de-configuration of external components is not encouraged and should be +done via hooks. Still we could easily support it via this extra argument. 4) What will be the script environment? @@ -123,9 +134,20 @@ might setup depending on instance tags (e.g. firewalls, etc) Configuration Changes ~~~~~~~~~~~~~~~~~~~~~ -Just an extra file installed under the same dir kvm-ifup resides. Plus an -extra file writen upon TAP creation named after the NIC's UUID and including -the TAP's name. +1) The `kvm-ifdown` script will be an extra file installed under the same dir + `kvm-ifup` resides. We could have a single script (and symbolic links to it) + that shares the same code, where a second positional argument or an extra + environment variable would define if we are bringing the interface up or + down. Still this is not the best practice since it is not equivalent + with how KVM uses `script` and `downscript` in the `netdev` option; scripts + are different files that get the tap name as positional argument. Of course + common code will go in `net-common` so that it can be sourced from either + Xen or KVM specific scripts. + +2) An extra file written upon TAP creation named after the NIC's UUID and + including the TAP's name. Since this should be the correct file to keep + backwards compatibility we create a symbolic link named after the NIC's + index and pointing to this new file. .. vim: set textwidth=72 : .. Local Variables:
signature.asc
Description: Digital signature
