Hi,

* Dimitris Aragiorgis <[email protected]> [2014-03-05 18:05:06 +0200]:

> * 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.
> 

Any news on this? Is there anything pending?

Thanks,
dimara

> 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:


Attachment: signature.asc
Description: Digital signature

Reply via email to