This bug was fixed in the package cloud-init - 0.7.9-153-g16a7302f-
0ubuntu1~17.04.2
---------------
cloud-init (0.7.9-153-g16a7302f-0ubuntu1~17.04.2) zesty-proposed; urgency=medium
* cherry-pick 5fb49bac: azure: identify platform by well known value
in chassis asset (LP: #1693939)
* cherry-pick 003c6678: net: remove systemd link file writing from eni
renderer
* cherry-pick 1cd4323b: azure: remove accidental duplicate line in
merge.
* cherry-pick ebc9ecbc: Azure: Add network-config, Refactor net layer
to handle duplicate macs. (LP: #1690430)
* cherry-pick 11121fe4: systemd: make cloud-final.service run before
apt daily (LP: #1693361)
-- Scott Moser <smo...@ubuntu.com> Wed, 28 Jun 2017 17:20:51 -0400
** Changed in: cloud-init (Ubuntu Zesty)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1690430
Title:
[Hyper-V] Advanced networking support on Azure
Status in cloud-init:
Fix Committed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Yakkety:
Won't Fix
Status in cloud-init source package in Zesty:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
A new feature in Azure allows instances the ability to utilize
SR-IOV networking. Currently, Ubuntu images will fail to boot there.
[Test Case]
Testing this comes in the following parts:
a.) check that no regressions have leaked in outside of Azure.
b.) upgraded instance without SR-IOV device upgrade and reboot.
c.) fresh instance with SR-IOV and updated cloud-init and reboot.
d.) fresh instance without SR-IOV and updated cloud-init and reboot.
The cases above generally verify that users have not been exposed
to unexpected changes in behavior, and that the fix is correctly
applied.
After each boot, the user should collect logs, and generally look around
for evidence of failure. One tool that can be used to collected these
logs is 'save-old-data' at [1]. That checks for many common issues with
systemd boot.
[1] https://git.launchpad.net/~smoser/cloud-init/+git/sru-
info/tree/bin/save-old-data
[Regression Potential]
The majority of the changes have been limited to the Azure code path.
Regressions then are likely limited to Azure users, and would most
likely present themselves as network configuration failures on reboot
or first boot.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=ebc9ecbc8a
=== End SRU Template ===
We are in the process of rolling out SR-IOV in Azure (available as a
preview now, contact me offline and we can work out getting your
subscription addedif you want to try it). In general our normal
synthetic interface appears as eth0 and the VF comes in as eth1. We
intend to bond these interfaces together so that if the VF goes down,
or the VM is migrated to where no VF is present, eth0 remains as the
valid default interface.
At the moment we are handling the bonding via this script:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/plain/tools/hv/bondvf.sh
We were looking at ways to either integrate the behavior into cloud-
init or invoke the script from cloud-init and do the right thing.
We recently observed after https://bugs.launchpad.net/ubuntu/+source
/cloud-init/+bug/1669860 that the VF interface gets renamed to
something like "enP1p0s2" but more recently as "rename2".
Is it possible that 1669860 needs to be expanded to cover our case or
is there something we should be doing to make sure that change is
working properly for SR-IOV in Azure?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1690430/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
