I'm here processing open-scsi in the Xenial and Yakkety SRU queues. However, I feel that this SRU is far from ready to be accepted into the proposed pockets and am inclined to reject the uploads to prevent further confusion.
1) Stakeholders don't appear to have consensus on how this problem should be fixed. Can you figure this out amongst yourselves before uploading? If you end up at an impasse, I'd appreciate a description and clarity on what the impasse is exactly to help the SRU team (or the TB if Zesty I guess) make a decision. 2) Given that the first attempt has regressed stable releases already and had to be backed out, I'd expect more effort to bake this in the development release first, rather than throwing it at stable releases at the same time. 3) I expect the "Test Case" and "Regression Potential" paperwork to make reference to the regression that has already hit the updates pocket, with a test plan to stop that sort of thing happening again, but these sections don't appear to have been touched. 4) open-iscsi, which is in the upload queue for Xenial and Yakkety, doesn't currently have its development task marked Fix Released and I see no explanation for this. I see that this is likely due to a dep8 failure blocking proposed migration. But given point 2, perhaps we shouldn't ignore that as it might be hiding a real failure? 5) It may be that the open-iscsi change itself is uncontroversial and that's why it is uploaded without the others. But if we did accept open- iscsi into proposed, then we'd end up with a verification-needed tag, which might soon turn into verification-done. If we then end up accepting initramfs-tools or isc-dhcp, then we may end up racing the tags, causing confusion and accidental release of an proposed update that has not been verified. I'd like to confirm with a more experienced SRU team member whether this could actually happen, but it seems to me that given the complexity of this SRU it would make more sense to first get consensus on all the changes intended to be landed to fix this issue, land everything into proposed at once, verify them both individually and functionally all together while they are all in proposed together, and then release them all together to the updates pocket. Doing them piecemeal doesn't make much sense to me, and I feel increases regression risk. Additionally one update could end up insufficient as you debate and change the approach, in which case we'd need an additional SRU (and risk another regression, etc) for no good reason. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1621507 Title: initramfs-tools configure_networking() fails to dhcp ipv6 addresses Status in MAAS: Fix Committed Status in initramfs-tools package in Ubuntu: In Progress Status in isc-dhcp package in Ubuntu: In Progress Status in klibc package in Ubuntu: Won't Fix Status in open-iscsi package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: Triaged Status in isc-dhcp source package in Xenial: In Progress Status in klibc source package in Xenial: Won't Fix Status in open-iscsi source package in Xenial: In Progress Status in initramfs-tools source package in Yakkety: In Progress Status in isc-dhcp source package in Yakkety: In Progress Status in klibc source package in Yakkety: Won't Fix Status in open-iscsi source package in Yakkety: In Progress Status in klibc package in Debian: New Bug description: initramfs' configure_networking function uses ipconfig to configure the network. ipconfig does not support dhcpv6. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164 Related bugs: * bug 1229458: grub2 needed changes * bug 1621615: network not configured when ipv6 netbooted into cloud-init * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6) [Impact] It is not possible to netboot Ubuntu with a network-based root filesystem in an ipv6-only environment. Anyone wanting to netboot in an ipv6-only environment is affected. These uploads address this by replacing the one-off klibc dhcp client (IPv4-only) with the defacto standard isc-dhcp-client, and thereby provide both ipv6 and ipv4 DHCP configuration. [Test Case] See Bug 1229458. Configure radvd, dhcpd, and tftpd for your ipv6-only netbooting world. Pass the boot process an ipv6 address to talk to, and see it fail to configure the network. [Regression Potential] 1) This increases the uncompressed initramfs size by approximately 500KB, since isc-dhcp-client is added, but klibc is still needed for some other things, and is therefore present. On systems with a very small /boot partition, this could result in failure to upgrade the initramfs. 2) In at least some cases, DHCP network configuration shifts from klibc's ipconfig to isc-dhcp-client's dhclient. This should be of minimal risk, as isc-dhcp-client is in very very widespread use. In the event of a regression, network boot would fail, but the prior kernel should still be bootable. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1621507/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
