cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

On Tue, Jan 9, 2018 at 5:31 PM, Sushant Sharma (AZURE) <
Sushant.Sharma@xxxxxxxxxxxxx> wrote:

> Hi cloud-init members,
>
>
>
> We would like to discuss with you our proposal to add a network module in
> cloud-init to support various networking scenarios in Azure.
>
> To begin with, we would like to support move of a virtual machine (VM)
> from one network to another in Azure.
>
> As such, it will listen for media disconnect/connect (via netlink) and
> issues a re-DHCP when required (this design is based on how azure moves VM
> from one network to another).
>

Thanks for starting the discussion here.  For this use-case, are you
migrating
the entire VM or are we changing an existing nic from one subnet to another?
Since the link goes down (stopping traffic), is it possible to remove the
nic
and re-add it instead?

Operating system behavior around link state change varies depending on the
network service managing things.  In Ubuntu where ifupdown and
isc-dhcp-client
are utilized, as you know, netlink changes are not handled.  Under Ubuntu
Artful
and Bionic which utilize systemd-networkd, link state changes are watched;
if
the device loses carrier then when it is restored networkd will reacquire a
lease in that
case.

Over time, we plan to support more advance networking scenarios in Azure.
> Please let us know your thoughts before we work on adding the module.
>

I'm very much interested in enumerating additional scenarios.  Some
user-stories
which I think need to be address:

1. add additional network device and configure
2. remove network device (and update configuration)
3. add additional ip addresses to one or more network devices
4. remove ip address from one or more network devices
5. modify the configuration of an existing network device (changes outside
   of 3 and 4)

Cases 1 and 2 are generally covered by a udev hook handler.  3 and 4 can be
partially addressed by updating cloud-init to read network config metadata
and
renderer a complete network configuration and may be combined with 1 and 2.

What's not easily covered by a udev hook is the case where users modify
existing
network configuration without adding or removing devices.  To handle this
sort
of scenario a cloud will need to provide some notification mechanism to
which
cloud-init can react.  This may be something simple like a websocket
cloud-init
can select() on, or some other hypervisor event injection.  This area is not
well defined and will certainly vary from provider to provider which will
require some time to form a general solution.

I'd like to continue the discussion in a shared document:

https://hackmd.io/MzCsBYBMEMHYCMC0AOS4BmjwAYCM3F54A2JGZAY3gCYBTaSYa2IA?both



>
> Thanks,
>
> Sushant
>
>
>
> --
> Mailing list: https://launchpad.net/~cloud-init
> Post to     : cloud-init@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cloud-init
> More help   : https://help.launchpad.net/ListHelp
>
>