This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.10.3
---
netplan.io (0.96-0ubuntu0.18.10.3) cosmic; urgency=medium
* debian/patches/git_revert_explicit_renderer_def_ebc212a.patch: revert
commit ebc212a: make renderer values explicit at the end of each parsing
This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.04.4
---
netplan.io (0.96-0ubuntu0.18.04.4) bionic; urgency=medium
* debian/patches/git_revert_explicit_renderer_def_ebc212a.patch: revert
commit ebc212a: make renderer values explicit at the end of each parsing
This is still verification-done for bionic and cosmic:
netplan.io/0.96-0ubuntu0.18.04.4
netplan.io/0.96-0ubuntu0.18.10.3
Confirmed that this is still working as expected with the new SRUs after
quickly re-verifying given the changes uploaded to fix the regression in
bug #1825206.
** Tags
Hello Alvaro, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.4 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package.
Hello Alvaro, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.3 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package.
A possible SRU regression has been reported against netplan.io
0.96-0ubuntu0.18.10.2 in LP: #1825206. This version has been rolled
back to -proposed while the investigation is ongoing.
** Changed in: netplan.io (Ubuntu Cosmic)
Status: Fix Released => Fix Committed
--
You received this
** Changed in: maas (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1804861
Title:
MTU size defined on /etc/netplan/50-cloud-init.yaml not applied
To
This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.10.2
---
netplan.io (0.96-0ubuntu0.18.10.2) cosmic; urgency=medium
* d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
Partially revert changes to networkd jobs ordering: leave systemd-networkd
This is still verification-done for bionic; re-upload was to skip some
failing tunnel tests due to a difference in kernel behavior.
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because you are a
Hello Alvaro, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.3 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package.
Setting verification-done tags for bionic and cosmic missing after
verification in comment #27.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You received this bug notification
Verification done with bionic and cosmic; using the following config:
network:
version: 2
ethernets:
ens4:
match:
macaddress: 52:54:00:ea:e6:7a
mtu: 9000
ens7:
match:
macaddress: 52:54:00:d7:62:4c
Hello Alvaro, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.1 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package.
** Description changed:
+ [Impact]
+ Users of netplan with complex bridge or bond configurations, where setting
MTU or renaming is required and matching is done by MAC address.
+
+ [Test case]
+ 1) Configure netplan with a bond, and device members that use different MTU
values:
+
+ network:
+
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: maas (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1804861
Title:
MTU
This bug was fixed in the package netplan.io - 0.95
---
netplan.io (0.95) disco; urgency=medium
* New upstream release:
- Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
- Added support for setting up IP tunnels; supporting the types: ipip,
MAAS picks up information at commissioning time about the system. This
would include the NIC driver, which could just as well be used as an
additional matching criterion in netplan YAML.
There's a limit to how much netplan can and should try to figure out
what one means: we're supposed to do
Thanks Steve; that's good to know. I think that will be very useful,
especially when deploying a machine that has hardware such as switch
ports, which may show up as separate interfaces but share a MAC. I'm
open to adding driver information in future releases.
We still need to be careful on this,
Hi Mike,
I broadly agree with your comments, but I want to note that:
On Wed, Dec 05, 2018 at 02:05:37AM -, Mike Pontillo wrote:
> I would love it if MAAS didn't need to send in the MAC at all.
> Unfortunately, I don't think this is viable long-term, as the kernel,
> plus algorithms for
This is a long thread; sorry for adding fuel to the fire. But I have a
some questions/comments.
(1) I feel like if we don't fix how matching works for 'ethernets' in
Netplan, we're not mapping the user's intent to an appropriate
configuration. The user is saying "I have two physical interfaces. I
It doesn't matter which process we use, it will be a big SRU regardless.
Also, of course it's an easy fix in MAAS, and it obviously works. I've
shown that setting no "macaddress" field in the netplan syntax does what
it should. Just don't specify a default for that value, and don't write
the
On Tue, Dec 4, 2018 at 12:31 PM Mathieu Trudel-Lapierre <
mathieu...@gmail.com> wrote:
> The problem is that DEVTYPE is unreliable at best. Using the MAC of one
> of the member interfaces is fine, but only if you really know what
> you're doing.
>
> I think we're otherwise back to matching by
The problem is that DEVTYPE is unreliable at best. Using the MAC of one
of the member interfaces is fine, but only if you really know what
you're doing.
I think we're otherwise back to matching by name instead of by MAC
address (or matching both), if you want to match "like ifupdown was
doing".
On Tue, Dec 4, 2018 at 10:30 AM Mathieu Trudel-Lapierre <
mathieu...@gmail.com> wrote:
> I disagree.
>
> We'd be working around a real design issue in systemd, rather that
>
While, I agree that having systemd-udev to apply MTU to devices is
less than ideal; I don't see having systemd or networkd
I disagree.
We'd be working around a real design issue in systemd, rather that
possibly matching against Type=ethernet (if that existed). I think we
should instead prioritize on avoiding this broken case in the other
parts of the networking stack, and make sure we fix systemd to provide
the right
25 matches
Mail list logo
