| 2017-02-15 06:15:19 |
Mike Pontillo |
bug |
|
|
added bug |
| 2017-02-15 06:23:30 |
Mike Pontillo |
summary |
No distinction between link-up and link-down unconfigured interfaces |
No distinction between link-up and link-down interfaces |
|
| 2017-02-15 06:24:15 |
Mike Pontillo |
description |
If I define an interface in netplan which has no DHCP type and no addresses, it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
|
| 2017-02-15 15:21:44 |
Ryan Harper |
bug |
|
|
added subscriber Ryan Harper |
| 2017-02-20 21:06:25 |
Mathieu Trudel-Lapierre |
netplan: status |
New |
Incomplete |
|
| 2017-02-20 21:06:27 |
Mathieu Trudel-Lapierre |
netplan: importance |
Undecided |
High |
|
| 2017-02-20 21:06:30 |
Mathieu Trudel-Lapierre |
netplan: assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2017-03-10 09:41:44 |
Mike Pontillo |
tags |
|
maas |
|
| 2017-03-10 09:42:40 |
Mike Pontillo |
bug task added |
|
maas |
|
| 2017-03-10 09:42:45 |
Mike Pontillo |
maas: status |
New |
Triaged |
|
| 2017-03-10 09:42:49 |
Mike Pontillo |
maas: importance |
Undecided |
Wishlist |
|
| 2017-05-19 15:13:00 |
Mathieu Trudel-Lapierre |
netplan: importance |
High |
Wishlist |
|
| 2017-05-19 15:13:02 |
Mathieu Trudel-Lapierre |
netplan: status |
Incomplete |
Triaged |
|
| 2017-05-23 23:05:08 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2017-05-25 19:49:08 |
Steve Langasek |
netplan: milestone |
|
netplan-17.05 |
|
| 2017-05-25 19:49:37 |
Steve Langasek |
netplan: importance |
Wishlist |
High |
|
| 2017-10-11 12:17:17 |
Francis Ginther |
tags |
maas |
id-59dd420cf831805e3c59b950 maas |
|
| 2017-11-23 08:48:32 |
Łukasz Zemczak |
bug task added |
|
nplan (Ubuntu) |
|
| 2017-11-23 08:48:41 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-11-23 08:48:41 |
Łukasz Zemczak |
bug task added |
|
nplan (Ubuntu Zesty) |
|
| 2017-11-23 08:48:41 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-11-23 08:48:41 |
Łukasz Zemczak |
bug task added |
|
nplan (Ubuntu Xenial) |
|
| 2017-11-23 15:14:30 |
Mathieu Trudel-Lapierre |
description |
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
[Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
|
| 2017-11-23 16:10:22 |
Łukasz Zemczak |
nplan (Ubuntu Zesty): status |
New |
Fix Committed |
|
| 2017-11-23 16:10:23 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-11-23 16:10:25 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2017-11-23 16:10:28 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-zesty |
|
| 2017-11-23 17:00:04 |
Łukasz Zemczak |
nplan (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2017-11-23 17:00:12 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-zesty |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-11-28 21:10:36 |
Mathieu Trudel-Lapierre |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-xenial verification-needed-zesty |
id-59dd420cf831805e3c59b950 maas verification-failed-xenial verification-needed verification-needed-zesty |
|
| 2017-11-29 21:26:41 |
Brian Murray |
tags |
id-59dd420cf831805e3c59b950 maas verification-failed-xenial verification-needed verification-needed-zesty |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-11-30 14:11:50 |
Eckhart Köppen |
bug |
|
|
added subscriber Eckhart Köppen |
| 2017-12-04 14:03:56 |
Mathieu Trudel-Lapierre |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-xenial verification-needed-zesty |
id-59dd420cf831805e3c59b950 maas verification-failed-xenial verification-needed verification-needed-zesty |
|
| 2017-12-05 09:14:21 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-failed-xenial verification-needed verification-needed-zesty |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-12-13 20:12:44 |
Mathieu Trudel-Lapierre |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-xenial verification-needed-zesty |
id-59dd420cf831805e3c59b950 maas verification-done-xenial verification-done-zesty |
|
| 2017-12-21 00:08:43 |
Anders Kaseorg |
bug |
|
|
added subscriber Anders Kaseorg |
| 2017-12-21 00:08:45 |
Launchpad Janitor |
nplan (Ubuntu): status |
New |
Confirmed |
|
| 2017-12-21 06:03:56 |
Chen-Han Hsiao (Stanley) |
bug |
|
|
added subscriber Chen-Han Hsiao (Stanley) |
| 2018-01-10 02:34:58 |
Launchpad Janitor |
nplan (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-01-10 02:35:54 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-01-10 02:37:12 |
Launchpad Janitor |
nplan (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2018-02-14 17:55:00 |
Mathieu Trudel-Lapierre |
netplan: status |
Triaged |
In Progress |
|
| 2018-02-20 05:26:33 |
Daniel Axtens |
bug |
|
|
added subscriber Daniel Axtens |
| 2018-02-28 00:54:30 |
Chris Halse Rogers |
nplan (Ubuntu Artful): status |
New |
Fix Committed |
|
| 2018-02-28 00:54:33 |
Chris Halse Rogers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-02-28 00:54:44 |
Chris Halse Rogers |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-xenial verification-done-zesty |
id-59dd420cf831805e3c59b950 maas verification-done-xenial verification-done-zesty verification-needed verification-needed-artful |
|
| 2018-03-05 13:15:39 |
Łukasz Zemczak |
nplan (Ubuntu Xenial): status |
Fix Released |
Fix Committed |
|
| 2018-03-05 13:16:44 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-xenial verification-done-zesty verification-needed verification-needed-artful |
id-59dd420cf831805e3c59b950 maas verification-done-xenial verification-done-zesty verification-needed verification-needed-artful verification-needed-xenial |
|
| 2018-03-05 13:18:51 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-xenial verification-done-zesty verification-needed verification-needed-artful verification-needed-xenial |
id-59dd420cf831805e3c59b950 maas verification-done-zesty verification-needed verification-needed-artful verification-needed-xenial |
|
| 2018-04-09 16:05:29 |
Mathieu Trudel-Lapierre |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-zesty verification-needed verification-needed-artful verification-needed-xenial |
id-59dd420cf831805e3c59b950 maas verification-done-artful verification-done-xenial verification-done-zesty |
|
| 2018-04-11 22:45:09 |
Launchpad Janitor |
nplan (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2018-04-12 08:48:55 |
Launchpad Janitor |
nplan (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-08-15 13:55:02 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu): status |
Confirmed |
In Progress |
|
| 2018-08-15 13:55:05 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Xenial): status |
Fix Released |
Fix Committed |
|
| 2018-08-15 13:55:09 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Xenial): status |
Fix Committed |
In Progress |
|
| 2018-08-15 13:55:12 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Zesty): status |
Fix Released |
In Progress |
|
| 2018-08-15 13:55:16 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Artful): status |
Fix Released |
In Progress |
|
| 2019-02-28 06:47:32 |
Mattias Thidell |
bug |
|
|
added subscriber Mattias Thidell |
| 2019-02-28 06:57:26 |
Mattias Thidell |
nplan (Ubuntu Xenial): status |
In Progress |
Fix Released |
|
| 2019-02-28 09:45:47 |
Steve Langasek |
nplan (Ubuntu Xenial): status |
Fix Released |
In Progress |
|
| 2019-05-16 20:52:15 |
Brian Murray |
nplan (Ubuntu Zesty): status |
In Progress |
Won't Fix |
|
| 2019-05-16 20:52:22 |
Brian Murray |
nplan (Ubuntu Artful): status |
In Progress |
Won't Fix |
|
| 2019-05-16 20:52:25 |
Mathieu Trudel-Lapierre |
bug task added |
|
systemd (Ubuntu) |
|
| 2019-05-16 20:53:48 |
Mathieu Trudel-Lapierre |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-artful verification-done-xenial verification-done-zesty |
id-59dd420cf831805e3c59b950 maas |
|
| 2019-05-16 20:54:31 |
Mathieu Trudel-Lapierre |
systemd (Ubuntu): status |
New |
In Progress |
|
| 2019-05-16 20:54:39 |
Mathieu Trudel-Lapierre |
systemd (Ubuntu Zesty): status |
New |
Won't Fix |
|
| 2019-05-16 20:54:53 |
Mathieu Trudel-Lapierre |
affects |
nplan (Ubuntu) |
netplan.io (Ubuntu) |
|
| 2019-05-16 20:55:04 |
Mathieu Trudel-Lapierre |
systemd (Ubuntu Xenial): status |
New |
Won't Fix |
|
| 2019-05-16 20:55:10 |
Mathieu Trudel-Lapierre |
netplan.io (Ubuntu Xenial): status |
In Progress |
Won't Fix |
|
| 2019-10-10 04:17:32 |
Ed Swarthout |
bug |
|
|
added subscriber Ed Swarthout |
| 2019-12-13 14:09:42 |
Dan Streetman |
systemd (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-12-13 14:21:34 |
Dan Streetman |
systemd (Ubuntu): status |
Fix Released |
Confirmed |
|
| 2019-12-13 14:21:39 |
Dan Streetman |
systemd (Ubuntu): status |
Confirmed |
New |
|
| 2020-06-07 14:50:40 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2020-10-28 19:23:49 |
Launchpad Janitor |
systemd (Ubuntu): status |
New |
Confirmed |
|
| 2020-11-03 19:44:43 |
Nicorac |
bug |
|
|
added subscriber Nicorac |
| 2020-11-06 10:01:22 |
Łukasz Zemczak |
netplan: assignee |
Mathieu Trudel-Lapierre (cyphermox) |
Łukasz Zemczak (sil2100) |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
nominated for series |
|
Ubuntu Groovy |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Groovy) |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
bug task added |
|
netplan.io (Ubuntu Groovy) |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
nominated for series |
|
Ubuntu Focal |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Focal) |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
bug task added |
|
netplan.io (Ubuntu Focal) |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Hirsute) |
|
| 2021-05-12 14:37:36 |
Dan Streetman |
bug task added |
|
netplan.io (Ubuntu Hirsute) |
|
| 2021-05-18 08:38:48 |
Łukasz Zemczak |
description |
[Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
[Impact]
Since very long, we had a feature request in netplan to determine the activation mode of a given network interface. We got requests to enable marking some interfaces as 'manual', meaning that networkd (or any other backend) would not control its state in any way, requiring the administrator to bring the interface up or down manually. The other request was to mark a interface as 'off', that is: forcing the network interface to always be down until the configuration option isn't changed.
This was mainly requested for the networkd backend and requires the new feature of specifying ActivationPolicy= for interfaces, alongside the required netplan changes.
This feature is present in systemd 248 - for netplan supported stable series we have decided to cherry-pick and backport this feature on top of current systemd. The networkd feature basically adds the following 5 ActivationPolicy modes: always-down, down, manual, up, always-up. For netplan purposes we only use 'always-down' and 'manual'.
The netplan feature, hopefully landing as part of 0.103, is called 'activation-mode' and supports two values: 'manual' and 'off'.
[Test Case]
For the systemd part:
* Bring up a VM test environment with either a dummy interface or an interface that can be safely manipulated.
* Upgrade systemd to the -proposed version
* For the target interface, create/modify the networkd configuration (for instance by adding /etc/systemd/network/20-<interface>.network) to include the ActivationPolicy= setting in [Link], for instance:
[Match]
Name=dummy0
[Network]
Address=192.168.10.30/24
Gateway=192.168.10.1
[Link]
ActivationPolicy=manual
* Try all 5 combinations of ActivationPolicy values: always-down, down, manual, up, always-up - doing `sudo networkctl reload` everytime and checking if the interface behaves as expected.
[Where problems could occur]
The patchset modifies quite a lot of code in the networkd link handling code paths, so regressions could appear in how networkd manages links - maybe by suddenly certain interfaces not getting brought up as they were before.
---
[Original Description]
[Old Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Old Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Old Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
|
| 2021-05-18 08:39:14 |
Łukasz Zemczak |
systemd (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2021-05-25 10:24:07 |
Łukasz Zemczak |
description |
[Impact]
Since very long, we had a feature request in netplan to determine the activation mode of a given network interface. We got requests to enable marking some interfaces as 'manual', meaning that networkd (or any other backend) would not control its state in any way, requiring the administrator to bring the interface up or down manually. The other request was to mark a interface as 'off', that is: forcing the network interface to always be down until the configuration option isn't changed.
This was mainly requested for the networkd backend and requires the new feature of specifying ActivationPolicy= for interfaces, alongside the required netplan changes.
This feature is present in systemd 248 - for netplan supported stable series we have decided to cherry-pick and backport this feature on top of current systemd. The networkd feature basically adds the following 5 ActivationPolicy modes: always-down, down, manual, up, always-up. For netplan purposes we only use 'always-down' and 'manual'.
The netplan feature, hopefully landing as part of 0.103, is called 'activation-mode' and supports two values: 'manual' and 'off'.
[Test Case]
For the systemd part:
* Bring up a VM test environment with either a dummy interface or an interface that can be safely manipulated.
* Upgrade systemd to the -proposed version
* For the target interface, create/modify the networkd configuration (for instance by adding /etc/systemd/network/20-<interface>.network) to include the ActivationPolicy= setting in [Link], for instance:
[Match]
Name=dummy0
[Network]
Address=192.168.10.30/24
Gateway=192.168.10.1
[Link]
ActivationPolicy=manual
* Try all 5 combinations of ActivationPolicy values: always-down, down, manual, up, always-up - doing `sudo networkctl reload` everytime and checking if the interface behaves as expected.
[Where problems could occur]
The patchset modifies quite a lot of code in the networkd link handling code paths, so regressions could appear in how networkd manages links - maybe by suddenly certain interfaces not getting brought up as they were before.
---
[Original Description]
[Old Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Old Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Old Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
[Impact]
Since very long, we had a feature request in netplan to determine the activation mode of a given network interface. We got requests to enable marking some interfaces as 'manual', meaning that networkd (or any other backend) would not control its state in any way, requiring the administrator to bring the interface up or down manually. The other request was to mark a interface as 'off', that is: forcing the network interface to always be down until the configuration option isn't changed.
This was mainly requested for the networkd backend and requires the new feature of specifying ActivationPolicy= for interfaces, alongside the required netplan changes.
This feature is present in systemd 248 - for netplan supported stable series we have decided to cherry-pick and backport this feature on top of current systemd. The networkd feature basically adds the following 5 ActivationPolicy modes: always-down, down, manual, up, always-up. For netplan purposes we only use 'always-down' and 'manual'.
The netplan feature, hopefully landing as part of 0.103, is called 'activation-mode' and supports two values: 'manual' and 'off'.
[Test Case]
For the systemd part:
* Bring up a VM test environment with either a dummy interface or an interface that can be safely manipulated.
* Upgrade systemd to the -proposed version
* For the target interface, create/modify the networkd configuration to include the ActivationPolicy= setting in [Link], for instance:
[Match]
Name=dummy0
[Network]
Address=192.168.10.30/24
Gateway=192.168.10.1
[Link]
ActivationPolicy=manual
* Try all 5 combinations of ActivationPolicy values: always-down, down, manual, up, always-up - doing `sudo networkctl reload` everytime and checking if the interface behaves as expected.
[Where problems could occur]
The patchset modifies quite a lot of code in the networkd link handling code paths, so regressions could appear in how networkd manages links - maybe by suddenly certain interfaces not getting brought up as they were before.
---
[Original Description]
[Old Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Old Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Old Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
|
| 2021-05-28 21:29:32 |
Steve Langasek |
description |
[Impact]
Since very long, we had a feature request in netplan to determine the activation mode of a given network interface. We got requests to enable marking some interfaces as 'manual', meaning that networkd (or any other backend) would not control its state in any way, requiring the administrator to bring the interface up or down manually. The other request was to mark a interface as 'off', that is: forcing the network interface to always be down until the configuration option isn't changed.
This was mainly requested for the networkd backend and requires the new feature of specifying ActivationPolicy= for interfaces, alongside the required netplan changes.
This feature is present in systemd 248 - for netplan supported stable series we have decided to cherry-pick and backport this feature on top of current systemd. The networkd feature basically adds the following 5 ActivationPolicy modes: always-down, down, manual, up, always-up. For netplan purposes we only use 'always-down' and 'manual'.
The netplan feature, hopefully landing as part of 0.103, is called 'activation-mode' and supports two values: 'manual' and 'off'.
[Test Case]
For the systemd part:
* Bring up a VM test environment with either a dummy interface or an interface that can be safely manipulated.
* Upgrade systemd to the -proposed version
* For the target interface, create/modify the networkd configuration to include the ActivationPolicy= setting in [Link], for instance:
[Match]
Name=dummy0
[Network]
Address=192.168.10.30/24
Gateway=192.168.10.1
[Link]
ActivationPolicy=manual
* Try all 5 combinations of ActivationPolicy values: always-down, down, manual, up, always-up - doing `sudo networkctl reload` everytime and checking if the interface behaves as expected.
[Where problems could occur]
The patchset modifies quite a lot of code in the networkd link handling code paths, so regressions could appear in how networkd manages links - maybe by suddenly certain interfaces not getting brought up as they were before.
---
[Original Description]
[Old Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Old Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Old Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
[Impact]
Since very long, we had a feature request in netplan to determine the activation mode of a given network interface. We got requests to enable marking some interfaces as 'manual', meaning that networkd (or any other backend) would not control its state in any way, requiring the administrator to bring the interface up or down manually. The other request was to mark a interface as 'off', that is: forcing the network interface to always be down until the configuration option isn't changed.
This was mainly requested for the networkd backend and requires the new feature of specifying ActivationPolicy= for interfaces, alongside the required netplan changes.
This feature is present in systemd 248 - for netplan supported stable series we have decided to cherry-pick and backport this feature on top of current systemd. The networkd feature basically adds the following 5 ActivationPolicy modes: always-down, down, manual, up, always-up. For netplan purposes we only use 'always-down' and 'manual'.
The netplan feature, hopefully landing as part of 0.103, is called 'activation-mode' and supports two values: 'manual' and 'off'.
[Test Case]
For the systemd part:
* Bring up a VM test environment with either a dummy interface or an interface that can be safely manipulated.
* Upgrade systemd to the -proposed version
* For the target interface, create/modify the networkd configuration to include the ActivationPolicy= setting in [Link], for instance:
[Match]
Name=dummy0
[Network]
Address=192.168.10.30/24
Gateway=192.168.10.1
[Link]
ActivationPolicy=manual
* Try all 5 combinations of ActivationPolicy values: always-down, down, manual, up, always-up - doing `sudo networkctl reload` everytime and checking if the interface behaves as expected.
[Where problems could occur]
The patchset modifies quite a lot of code in the networkd link handling code paths, so regressions could appear in how networkd manages links - maybe by suddenly certain interfaces not getting brought up as they were before. By code inspection, the implementation defaults to ACTIVATION_POLICY_UP as the default, equivalent to the current behavior, so this risk is small.
---
[Original Description]
[Old Impact]
Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional".
[Old Test case]
Write a netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
eth0:
optional: yes
dhcp4: yes
And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error.
[Old Regression potential]
This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.
---
If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down).
I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS.
If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down.
There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) |
|
| 2021-06-01 22:45:24 |
Brian Murray |
systemd (Ubuntu Hirsute): status |
New |
Fix Committed |
|
| 2021-06-01 22:45:36 |
Brian Murray |
tags |
id-59dd420cf831805e3c59b950 maas |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-hirsute |
|
| 2021-06-01 22:59:53 |
Brian Murray |
systemd (Ubuntu Groovy): status |
New |
Fix Committed |
|
| 2021-06-01 23:00:04 |
Brian Murray |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-hirsute |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-groovy verification-needed-hirsute |
|
| 2021-06-01 23:06:29 |
Brian Murray |
systemd (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2021-06-01 23:06:41 |
Brian Murray |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-groovy verification-needed-hirsute |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-focal verification-needed-groovy verification-needed-hirsute |
|
| 2021-06-08 08:18:08 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-needed verification-needed-focal verification-needed-groovy verification-needed-hirsute |
id-59dd420cf831805e3c59b950 maas verification-done-focal verification-needed verification-needed-groovy verification-needed-hirsute |
|
| 2021-06-10 09:08:52 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-focal verification-needed verification-needed-groovy verification-needed-hirsute |
id-59dd420cf831805e3c59b950 maas verification-done-focal verification-done-groovy verification-needed verification-needed-hirsute |
|
| 2021-06-10 09:35:01 |
Łukasz Zemczak |
tags |
id-59dd420cf831805e3c59b950 maas verification-done-focal verification-done-groovy verification-needed verification-needed-hirsute |
id-59dd420cf831805e3c59b950 maas verification-done verification-done-focal verification-done-groovy verification-done-hirsute |
|
| 2021-06-16 15:27:08 |
Launchpad Janitor |
systemd (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-06-16 15:29:48 |
Launchpad Janitor |
systemd (Ubuntu Groovy): status |
Fix Committed |
Fix Released |
|
| 2021-06-16 15:35:19 |
Launchpad Janitor |
systemd (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-06-28 22:06:27 |
Dan Streetman |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-06-28 22:06:27 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Bionic) |
|
| 2021-06-28 22:06:27 |
Dan Streetman |
bug task added |
|
netplan.io (Ubuntu Bionic) |
|
| 2021-06-28 22:06:51 |
Dan Streetman |
systemd (Ubuntu Bionic): status |
New |
Won't Fix |
|
| 2021-06-28 22:07:17 |
Dan Streetman |
netplan.io (Ubuntu Bionic): status |
New |
Won't Fix |
|
| 2021-08-06 16:16:55 |
Launchpad Janitor |
netplan.io (Ubuntu): status |
In Progress |
Fix Released |
|
| 2021-08-06 16:16:55 |
Launchpad Janitor |
bug watch added |
|
https://github.com/systemd/systemd/issues/18108 |
|
| 2022-03-16 16:06:44 |
Lukas Märdian |
netplan: status |
In Progress |
Fix Released |
|
| 2022-03-16 16:06:54 |
Lukas Märdian |
netplan.io (Ubuntu Focal): status |
New |
Fix Released |
|
| 2022-03-16 16:07:13 |
Lukas Märdian |
netplan.io (Ubuntu Hirsute): status |
New |
Fix Released |
|
| 2022-03-16 16:07:26 |
Lukas Märdian |
netplan.io (Ubuntu Groovy): status |
New |
Won't Fix |
|
| 2022-08-04 08:57:07 |
Jerzy Husakowski |
maas: status |
Triaged |
Won't Fix |
|
