cloud-init-dev team mailing list archive

[Mike Gerdts <mike.gerdts@xxxxxxxxxx>]

This knob would be exposed to the owner of the VM, with the default of
having it disabled.  A such, user changes would be preserved in the default
case.  The cloud customer that desires to have updates automatically
applied on reboot would need to set this, potentially at the same time that
networking changes are being made that make it necessary.

For hotplug to be a reality on SmartOS, we would need to do work on the
host side too.  Currently we have no way to hot-plug virtual nics, new
anti-spoofing rules (L2, L3) are only applied at boot, etc.  Hotplug of new
routes should work fine without host changes.  Presumably the host-side
changes that would be needed to support hotplug could make maintain_network
mutually exclusive with hotplug support (if necessary).

I appreciate your concern about feature sprawl that makes future work more
difficult.  At first blush, the risk in this case seems minimal.


On Fri, Apr 20, 2018 at 1:16 PM, Scott Moser <ssmoser2+ubuntu@xxxxxxxxx>
wrote:

> I'm not sure how I feel about this.
> Updating networking per the metadata service on reboot is *better* in this
> case than only doing it once.  But then we potentially step on user changes.
>
> We do plan to have "hotplug" (or *some-event* based) updating of
> networking information.
> The ultimate goal being for some event (such as a new nic being attached,
> or a signal from the hypervisor) to trigger cloud-init to update the
> networking.
>
> I'm worried that taking this might convolute things on our way to getting
> to that more ideal solution.
>
> --
> https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-
> init/+merge/343712
> You are the owner of ~mgerdts/cloud-init:lp1765801.
>

-- 
https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-init/+merge/343712
Your team cloud-init commiters is requested to review the proposed merge of ~mgerdts/cloud-init:lp1765801 into cloud-init:master.