Re: [pve-devel] [PATCH close #545, #5203: Allow bridges to have any valid interface name 0/2]
--- Begin Message --- >>It might make sense to check for any possible conflicts with the SDN >>config (running & staged). Technically, ifupdown2 will try to merge config options, if the interface is defined in both /etc/network/interfaces && /etc/network/interfaces.d/ I have seen user doing some specific tuning on vnet like this: /etc/network/interfaces iface vnet1 otheroptions .. /etc/network/interfaces.d/ iface vnet1 address bridge_ports ... Message initial De: Stefan Hanreich Répondre à: Proxmox VE development discussion À: Proxmox VE development discussion , Jillian Morgan Objet: Re: [pve-devel] [PATCH close #545, #5203: Allow bridges to have any valid interface name 0/2] Date: 21/02/2024 15:21:06 It might make sense to check for any possible conflicts with the SDN config (running & staged). --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH close #545, #5203: Allow bridges to have any valid interface name 0/2]
Am 22/02/2024 um 09:00 schrieb DERUMIER, Alexandre: >>> It might make sense to check for any possible conflicts with the SDN >>> config (running & staged). > > Technically, ifupdown2 will try to merge config options, if the > interface is defined in both /etc/network/interfaces && > /etc/network/interfaces.d/ So we basically it could be fine to only show a warning (or hint) in either: - node-specific bridge create if a vnet with that name already exists - vnet create, if such a bridge already exists And similar for edit and deletions, as a user might wonder why the bridge is still there if one deleted either vnet or the bridge entry. As then the user is aware of it and can better decide if they indeed to create such a duplication. That might be a bit more work for one not used to our code base though, so for starters adding a hint to the documentation could be enough. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server 4/4] cpu config: Unify the default value for 'kvm'
Am 21.02.24 um 16:39 schrieb Filip Schauer:
> On 19/02/2024 15:47, Fiona Ebner wrote:
>> On an x86_64 host, for guests using a different architecture (i.e.
>> aarch64), hot-plugging is already broken, because we try to hotplug a
>> CPU of type "$cpu-x86_64-cpu,XYZ" which won't work anyways:
>>
>> vcpus: hotplug problem - VM 130 qmp command 'device_add' failed -
>> 'kvm64-x86_64-cpu' is not a valid device model name
>>
>> The actual breaking change is for the host arch being something other
>> than x86_64 (which isn't officially supported) and the VM being
>> x86_64, ...
>>
>>> @@ -414,9 +415,9 @@ sub get_custom_model {
>>> # Print a QEMU device node for a given VM configuration for
>>> hotplugging CPUs
>>> sub print_cpu_device {
>>> - my ($conf, $id) = @_;
>>> + my ($conf, $arch, $id) = @_;
>>> - my $kvm = $conf->{kvm} // 1;
>>> + my $kvm = $conf->{kvm} // is_native($arch);
>>> my $cpu = get_default_cpu_type('x86_64', $kvm);
>> ...because in that case, before this patch we got kvm64 here, but with
>> the patch we get qemu64 which would be a problem for live-migration.
>
> I expressed my opinion on this matter in the following mail:
>
> https://lists.proxmox.com/pipermail/pve-devel/2023-December/061131.html
>
Yes, I also think the change is fine. But breaking ARM64 guests on a
x86_64 host would not be fine. The point is CPU hotplug already doesn't
work here, so the commit message should be adapted to mention that.
I saw you completely removed the commit message in v8. Should be added
back with the additional information, but that alone doesn't warrant a
v9, can also be done when applying.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 0/7] add dhcp support for all zones
On 12/22/23 22:27, DERUMIER, Alexandre wrote:
> Hi,
> I'll be on holiday next week (I'll be back the 2 january).
>
>
> I'll look at QinQ when I'll be back.
I've had another look at this patch series and I think I found the
reason for the issue(s) I encountered during my testing.
One issue is related to the new IP forwarding settings. It seems like
they are not applying. I've looked at the ifquery output after creating
a QinQ / VLAN zone with DHCP enabled:
{
"name": "qinq5",
"auto": true,
"config": {
"bridge-ports": "z_qinq5.456",
"bridge-stp": "no",
"bridge-fd": "0",
"ip-forward": "on",
"address": "172.16.5.1/32"
},
"config_status": {
"bridge-ports": "pass",
"bridge-stp": "pass",
"bridge-fd": "pass",
"ip-forward": "fail",
"address": "pass"
},
"status": "fail"
},
{
"name": "vlan4",
"auto": true,
"config": {
"bridge-ports": "ln_vlan4",
"bridge-stp": "no",
"bridge-fd": "0",
"ip-forward": "on",
"address": "172.16.4.1/32"
},
"config_status": {
"bridge-ports": "pass",
"bridge-stp": "pass",
"bridge-fd": "pass",
"ip-forward": "fail",
"address": "pass"
},
"status": "fail"
},
It seems like the ip-forward settings do not get applied and therefore
the command 'fails'. The bridges are up and working but IP forwarding is
enabled:
root@hoan-02:~# cat /proc/sys/net/ipv4/conf/vlan4/forwarding
1
root@hoan-02:~# cat /proc/sys/net/ipv4/conf/qinq5/forwarding
1
The other issue was using QinQ zone with a bridge that has no bridge
port configured and is not vlan-aware. In that case status is checking
for the existence of the sv_ interface but it doesn't exist since
there isn't a bridge port.
This is also occuring without this patch, so no show stopper here imo.
> It just miss the ip for dhcpserver different than gateway for ipv6
> handling for vlan/qinq/vxlan, but it should be easy to implement.
>
> Also, for ipv6 in vrf, it need a patch for dnsmasq, so I think this
> will need to proxmox dnsmasq package version.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 0/7] add dhcp support for all zones
--- Begin Message --- Hi Stefan ! I don't known the roadmap for dhcp, but I'll have time to help in March. I don't have looked at qinq yet. >>I've had another look at this patch series and I think I found the >>reason for the issue(s) I encountered during my testing. >> >>One issue is related to the new IP forwarding settings. It seems like >>they are not applying. I've looked at the ifquery output after >>creating >>a QinQ / VLAN zone with DHCP enabled: >>It seems like the ip-forward settings do not get applied and >>therefore >>the command 'fails'. The bridges are up and working but IP forwarding >>is >>enabled: >> >>root@hoan-02:~# cat /proc/sys/net/ipv4/conf/vlan4/forwarding >>1 >> >>root@hoan-02:~# cat /proc/sys/net/ipv4/conf/qinq5/forwarding >>1 what is the output of "ifreload -a -d" ? >>The other issue was using QinQ zone with a bridge that has no bridge >>port configured and is not vlan-aware. In that case status is >>checking >>for the existence of the sv_ interface but it doesn't exist since >>there isn't a bridge port. >>This is also occuring without this patch, so no show stopper here imo. mmm, good catch, I'll look to add a check for this. I'll check too for vlan zone, with non vlan-aware bridge without interface. BTW, for dnsmasq + ipv6 with evpn/vrf, we need to add a patch. What do you think about providing a proxmox package for dnsmasq with this patch, + remove the default dnsmasq service. (as currently it's a little bit hacky, with manually disabling the main service) > It just miss the ip for dhcpserver different than gateway for ipv6 > handling for vlan/qinq/vxlan, but it should be easy to implement. > > Also, for ipv6 in vrf, it need a patch for dnsmasq, so I think this > will need to proxmox dnsmasq package version. --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server v8 6/7] check_local_resources: virtiofs
On 2024-01-31 16:35, Fiona Ebner wrote: A 'migration: ' prefix would be nice for the commit title. Am 08.11.23 um 09:52 schrieb Markus Frank: add dir mapping checks to check_local_resources So, as long as there is a mapping for the target node, the migration check goes through. Should it? I mean, nothing ensures that the contents of the directory are the same on the target, or? What happens if they are not? Yes. This is similar to the PCI & USB Mapping. Nothing ensures that the mapped device/directory is the same on the other host. If the contents are not the same they will not be the same. But this should not be a problem as long as nothing in a VM depends on something in the virtiofs directory. This is something the user should take care of. Or am I missing something? Is migration with a directory on a shared storage reliable? With all cache settings? I didn't encounter any problems. Since the VM has to be powered off to migrate, I assume the cache gets cleared & written to disk when virtiofs stops. If you already tested these things, please share them in the commit message (and maybe also docs). Otherwise, I know nothing without testing myself ;) Okay :) ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 0/7] add dhcp support for all zones
On 2/22/24 11:41, DERUMIER, Alexandre wrote: > what is the output of "ifreload -a -d" ? nothing mentioning ip-forward sadly, I had already looked at /var/log/ifupdown2 to get an idea of what's going wrong but I couldn't find anything mentioned there as well (I think the output is the same..). I think it might just get ignored when applying - but not when checking. I guess I'll have to dig deeper into ifupdown2... > mmm, good catch, I'll look to add a check for this. > I'll check too for vlan zone, with non vlan-aware bridge without > interface. Yes, it shouldn't be too hard to check. I can also do this while I'm at it. > BTW, for dnsmasq + ipv6 with evpn/vrf, we need to add a patch. > > What do you think about providing a proxmox package for dnsmasq with > this patch, + remove the default dnsmasq service. (as currently it's > a little bit hacky, with manually disabling the main service) It's hard to tell - not sure if we want to take on the work of maintaining a separate dnsmasq package. I'll try and talk with Wolfgang / Thomas about this (or maybe they're reading this and can chime in?). ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 0/7] add dhcp support for all zones
--- Begin Message --- > what is the output of "ifreload -a -d" ? >>nothing mentioning ip-forward sadly, I had already looked at >>/var/log/ifupdown2 to get an idea of what's going wrong but I >>couldn't >>find anything mentioned there as well (I think the output is the >>same..). I think it might just get ignored when applying - but not >>when >>checking. >> >>I guess I'll have to dig deeper into ifupdown2... Ok, I have found it. ip-forward 1|0 is not applied on bridge. It's only done dynamically if bridge have an ip-adress or not currently I have send patch upstream: https://github.com/CumulusNetworks/ifupdown2/pull/292 I'll send a patch on pve-devel today or tomorrow. --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] sdn: vnets: Hide irrelevant fields depending on zone type
ping
still applies on current master
On 12/22/23 11:43, Stefan Hanreich wrote:
> Not all fields in the VnetEdit dialog are necessary for every zone
> type. This lead to confusion for some users. Hide fields in the
> VNetEdit dialog depending on which kind of zone is selected in order
> to prevent potential confusion.
>
> Signed-off-by: Stefan Hanreich
> ---
> www/manager6/form/SDNZoneSelector.js | 2 +-
> www/manager6/sdn/VnetEdit.js | 40
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/www/manager6/form/SDNZoneSelector.js
> b/www/manager6/form/SDNZoneSelector.js
> index 28c3457d2..0d0327529 100644
> --- a/www/manager6/form/SDNZoneSelector.js
> +++ b/www/manager6/form/SDNZoneSelector.js
> @@ -40,7 +40,7 @@ Ext.define('PVE.form.SDNZoneSelector', {
> }, function() {
> Ext.define('pve-sdn-zone', {
> extend: 'Ext.data.Model',
> - fields: ['zone'],
> + fields: ['zone', 'type'],
> proxy: {
> type: 'proxmox',
> url: "/api2/json/cluster/sdn/zones",
> diff --git a/www/manager6/sdn/VnetEdit.js b/www/manager6/sdn/VnetEdit.js
> index cdd83ed40..9fb6cd6c7 100644
> --- a/www/manager6/sdn/VnetEdit.js
> +++ b/www/manager6/sdn/VnetEdit.js
> @@ -12,6 +12,13 @@ Ext.define('PVE.sdn.VnetInputPanel', {
> return values;
> },
>
> +initComponent: function() {
> + let me = this;
> +
> + me.callParent();
> + me.setZoneType(undefined);
> +},
> +
> items: [
> {
> xtype: 'pmxDisplayEditField',
> @@ -40,9 +47,21 @@ Ext.define('PVE.sdn.VnetInputPanel', {
> name: 'zone',
> value: '',
> allowBlank: false,
> + listeners: {
> + change: function() {
> + let me = this;
> +
> + let record = me.findRecordByValue(me.value);
> + let zoneType = record?.data?.type;
> +
> + let panel = me.up('panel');
> + panel.setZoneType(zoneType);
> + },
> + },
> },
> {
> xtype: 'proxmoxintegerfield',
> + itemId: 'sdnVnetTagField',
> name: 'tag',
> minValue: 1,
> maxValue: 16777216,
> @@ -54,6 +73,7 @@ Ext.define('PVE.sdn.VnetInputPanel', {
> },
> {
> xtype: 'proxmoxcheckbox',
> + itemId: 'sdnVnetVlanAwareField',
> name: 'vlanaware',
> uncheckedValue: null,
> checked: false,
> @@ -63,6 +83,26 @@ Ext.define('PVE.sdn.VnetInputPanel', {
> },
> },
> ],
> +
> +setZoneType: function(zoneType) {
> + let me = this;
> +
> + let tagField = me.down('#sdnVnetTagField');
> + if (!zoneType || zoneType === 'simple') {
> + tagField.setVisible(false);
> + tagField.setValue('');
> + } else {
> + tagField.setVisible(true);
> + }
> +
> + let vlanField = me.down('#sdnVnetVlanAwareField');
> + if (!zoneType || zoneType === 'evpn') {
> + vlanField.setVisible(false);
> + vlanField.setValue('');
> + } else {
> + vlanField.setVisible(true);
> + }
> +},
> });
>
> Ext.define('PVE.sdn.VnetEdit', {
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 0/3] Advertise MTU via DHCP / RA
ping still applies on current master On 12/14/23 17:46, Stefan Hanreich wrote: > Stefan Hanreich (3): > dhcp: fix function signatures in abstract class > zones: add method for getting MTU > dhcp: dnsmasq: send mtu option via dhcp > > src/PVE/Network/SDN/Dhcp.pm | 2 +- > src/PVE/Network/SDN/Dhcp/Dnsmasq.pm | 7 ++- > src/PVE/Network/SDN/Dhcp/Plugin.pm| 12 ++-- > src/PVE/Network/SDN/Zones.pm | 8 > src/PVE/Network/SDN/Zones/Plugin.pm | 7 +++ > src/PVE/Network/SDN/Zones/SimplePlugin.pm | 8 +++- > 6 files changed, 35 insertions(+), 9 deletions(-) > ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH installer v2 0/7] gui: use gtk grids when possible
ping, still applies. Maximiliano Sandoval writes: > ping 👻 > > Maximiliano Sandoval writes: > >> ping >> >> Maximiliano Sandoval writes: -- Maximiliano ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network 0/2] allow ip|ip6-forward option on bridge
Currently, it's not working only for bridge, because we have a return after bridge default forwarding setup. Alexandre Derumier (2): patches: update slaac patch patches: allow ip|ip6-forward option on bridge debian/patches/series | 1 + ...6-slaac-support-inet6-auto-accept_ra.patch | 32 +++ ...dress-allow-ip-ip6-forward-on-bridge.patch | 32 +++ 3 files changed, 45 insertions(+), 20 deletions(-) create mode 100644 debian/patches/upstream/0001-address-allow-ip-ip6-forward-on-bridge.patch -- 2.39.2 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network 2/2] patches: allow ip|ip6-forward option on bridge
Signed-off-by: Alexandre Derumier --- debian/patches/series | 1 + ...dress-allow-ip-ip6-forward-on-bridge.patch | 32 +++ 2 files changed, 33 insertions(+) create mode 100644 debian/patches/upstream/0001-address-allow-ip-ip6-forward-on-bridge.patch diff --git a/debian/patches/series b/debian/patches/series index 557aa7f..3b80321 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -7,6 +7,7 @@ pve/0006-openvswitch-ovs-ports-condone-regex-exclude-tap-veth.patch pve/0007-allow-vlan-tag-inside-vxlan-tunnel.patch pve/0008-lacp-bond-remove-bond-min-links-0-warning.patch pve/0009-gvgeb-fix-python-interpreter-shebang.patch +upstream/0001-address-allow-ip-ip6-forward-on-bridge.patch upstream/0001-add-ipv6-slaac-support-inet6-auto-accept_ra.patch upstream/0001-addons-ethtool-add-rx-vlan-filter.patch upstream/0001-scheduler-import-traceback.patch diff --git a/debian/patches/upstream/0001-address-allow-ip-ip6-forward-on-bridge.patch b/debian/patches/upstream/0001-address-allow-ip-ip6-forward-on-bridge.patch new file mode 100644 index 000..b61d891 --- /dev/null +++ b/debian/patches/upstream/0001-address-allow-ip-ip6-forward-on-bridge.patch @@ -0,0 +1,32 @@ +From cd21f46308052ae092d1036886cde2c3177e3642 Mon Sep 17 00:00:00 2001 +From: Alexandre Derumier +Date: Thu, 22 Feb 2024 13:11:02 +0100 +Subject: [PATCH 2/2] address: allow ip|ip6-forward on bridge + +Currently, a bridge always have forward enabled if an ip exist, +or disabled if not ip is present. + +we can't use ip-forward on|off to override it because of this return. + +Signed-off-by: Alexandre Derumier +Signed-off-by: Alexandre Derumier +--- + ifupdown2/addons/address.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ifupdown2/addons/address.py b/ifupdown2/addons/address.py +index bb5589e..7310646 100644 +--- a/ifupdown2/addons/address.py b/ifupdown2/addons/address.py +@@ -984,7 +984,7 @@ class address(AddonWithIpBlackList, moduleBase): + + if (ifaceobj.link_kind & ifaceLinkKind.BRIDGE): + self._set_bridge_forwarding(ifaceobj) +-return ++ + if not self.syntax_check_sysctls(ifaceobj): + return + if not self.syntax_check_l3_svi_ip_forward(ifaceobj): +-- +2.39.2 + -- 2.39.2 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network 1/2] patches: update slaac patch
remove self._sysctl_slaac call for bridge, or it'll be called twice
Signed-off-by: Alexandre Derumier
---
...6-slaac-support-inet6-auto-accept_ra.patch | 32 +++
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git
a/debian/patches/upstream/0001-add-ipv6-slaac-support-inet6-auto-accept_ra.patch
b/debian/patches/upstream/0001-add-ipv6-slaac-support-inet6-auto-accept_ra.patch
index 9e1bb13..a8d6106 100644
---
a/debian/patches/upstream/0001-add-ipv6-slaac-support-inet6-auto-accept_ra.patch
+++
b/debian/patches/upstream/0001-add-ipv6-slaac-support-inet6-auto-accept_ra.patch
@@ -1,7 +1,7 @@
-From 76721af329cab107e339fef5bc783dacb32132dc Mon Sep 17 00:00:00 2001
+From fd844b0557337e714a7e11ed6c39bc8164709a46 Mon Sep 17 00:00:00 2001
From: Alexandre Derumier
Date: Tue, 9 May 2023 17:48:14 +0200
-Subject: [PATCH] add ipv6 slaac support (inet6 auto && accept_ra)
+Subject: add ipv6 slaac support (inet6 auto && accept_ra)
This should fix a lot of users request in the forum,
and also fix upgrade from ifupdown1 to ifupdown2 if user have "inet6 auto" in
configuration.
@@ -13,7 +13,7 @@ https://github.com/CumulusNetworks/ifupdown2/pull/259
Signed-off-by: Alexandre Derumier
---
etc/network/ifupdown2/addons.conf | 2 +
- ifupdown2/addons/address.py | 109 +--
+ ifupdown2/addons/address.py | 108 +--
ifupdown2/addons/auto.py| 168
ifupdown2/addons/dhcp.py| 18 +--
ifupdown2/ifupdown/iface.py | 4 +
@@ -21,11 +21,11 @@ Signed-off-by: Alexandre Derumier
ifupdown2/lib/nlcache.py| 63 -
ifupdown2/man/interfaces.5.rst | 9 ++
ifupdown2/nlmanager/nlpacket.py | 24 +++-
- 9 files changed, 373 insertions(+), 26 deletions(-)
+ 9 files changed, 372 insertions(+), 26 deletions(-)
create mode 100644 ifupdown2/addons/auto.py
diff --git a/etc/network/ifupdown2/addons.conf
b/etc/network/ifupdown2/addons.conf
-index 726d63a..67de25f 100644
+index a8f2317..5a3964d 100644
--- a/etc/network/ifupdown2/addons.conf
+++ b/etc/network/ifupdown2/addons.conf
@@ -15,6 +15,7 @@ pre-up,mstpctl
@@ -36,7 +36,7 @@ index 726d63a..67de25f 100644
pre-up,address
up,dhcp
up,address
-@@ -28,6 +29,7 @@ pre-down,usercmds
+@@ -30,6 +31,7 @@ pre-down,usercmds
pre-down,vxrd
pre-down,dhcp
down,ppp
@@ -45,7 +45,7 @@ index 726d63a..67de25f 100644
down,address
down,usercmds
diff --git a/ifupdown2/addons/address.py b/ifupdown2/addons/address.py
-index e71a26f..473a089 100644
+index e71a26f..bb5589e 100644
--- a/ifupdown2/addons/address.py
+++ b/ifupdown2/addons/address.py
@@ -188,6 +188,19 @@ class address(AddonWithIpBlackList, moduleBase):
@@ -177,15 +177,7 @@ index e71a26f..473a089 100644
def _sysctl_config(self, ifaceobj):
setting_default_value = False
mpls_enable = ifaceobj.get_attr_value_first('mpls-enable');
-@@ -912,6 +984,7 @@ class address(AddonWithIpBlackList, moduleBase):
-
- if (ifaceobj.link_kind & ifaceLinkKind.BRIDGE):
- self._set_bridge_forwarding(ifaceobj)
-+self._sysctl_slaac(ifaceobj)
- return
- if not self.syntax_check_sysctls(ifaceobj):
- return
-@@ -979,6 +1052,8 @@ class address(AddonWithIpBlackList, moduleBase):
+@@ -979,6 +1051,8 @@ class address(AddonWithIpBlackList, moduleBase):
ifaceobj.status = ifaceStatus.ERROR
self.logger.error('%s: %s' %(ifaceobj.name, str(e)))
@@ -194,7 +186,7 @@ index e71a26f..473a089 100644
def process_mtu(self, ifaceobj, ifaceobj_getfunc):
if ifaceobj.link_privflags & ifaceLinkPrivFlags.OPENVSWITCH:
-@@ -1016,7 +1091,7 @@ class address(AddonWithIpBlackList, moduleBase):
+@@ -1016,7 +1090,7 @@ class address(AddonWithIpBlackList, moduleBase):
# no need to go further during perfmode (boot)
return
@@ -203,7 +195,7 @@ index e71a26f..473a089 100644
return
if not user_configured_ipv6_addrgen:
-@@ -1213,7 +1288,7 @@ class address(AddonWithIpBlackList, moduleBase):
+@@ -1213,7 +1287,7 @@ class address(AddonWithIpBlackList, moduleBase):
if not self.cache.link_exists(ifaceobj.name):
return
addr_method = ifaceobj.addr_method
@@ -212,7 +204,7 @@ index e71a26f..473a089 100644
if ifaceobj.get_attr_value_first('address-purge')=='no':
addrlist = ifaceobj.get_attr_value('address')
for addr in addrlist or []:
-@@ -1326,6 +1401,22 @@ class address(AddonWithIpBlackList, moduleBase):
+@@ -1326,6 +1400,22 @@ class address(AddonWithIpBlackList, moduleBase):
ifaceobjcurr.update_config_with_status('mpls-enable',
running_mpls_enable,
mpls_enable !=
running_mpls_en
[pve-devel] [PATCH pve-manager v2] sdn: evpn: allow empty primary exit node in zone form
its broken since the change in semantics of the PUT endpoint [1]
[1]
https://git.proxmox.com/?p=pve-network.git;a=commit;h=3e3cafabaf955d53c4c2d4e346bf5c3a5c6d1852
Signed-off-by: Stefan Hanreich
Originally-by: Alexandre Derumier
---
www/manager6/sdn/zones/EvpnEdit.js | 2 ++
1 file changed, 2 insertions(+)
diff --git a/www/manager6/sdn/zones/EvpnEdit.js
b/www/manager6/sdn/zones/EvpnEdit.js
index a08faef2d..b4d982bd7 100644
--- a/www/manager6/sdn/zones/EvpnEdit.js
+++ b/www/manager6/sdn/zones/EvpnEdit.js
@@ -54,6 +54,8 @@ Ext.define('PVE.sdn.zones.EvpnInputPanel', {
fieldLabel: gettext('Primary Exit Node'),
multiSelect: false,
autoSelect: false,
+ skipEmptyText: true,
+ deleteEmpty: !me.isCreate,
},
{
xtype: 'proxmoxcheckbox',
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] sdn: evpn: allow empty primary exit node in zone form
This was broken when adding a new EVPN zone and there's an easier way
built-in to our widget toolkit. I've taken the liberty of sending a v2
and mentioning you [1].
[1] https://lists.proxmox.com/pipermail/pve-devel/2024-February/061924.html
On 2/13/24 11:40, Alexandre Derumier wrote:
> It's broken since
> https://git.proxmox.com/?p=pve-network.git;a=commit;h=3e3cafabaf955d53c4c2d4e346bf5c3a5c6d1852
>
> Signed-off-by: Alexandre Derumier
> ---
> www/manager6/sdn/zones/EvpnEdit.js | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/www/manager6/sdn/zones/EvpnEdit.js
> b/www/manager6/sdn/zones/EvpnEdit.js
> index a08faef2..2e792322 100644
> --- a/www/manager6/sdn/zones/EvpnEdit.js
> +++ b/www/manager6/sdn/zones/EvpnEdit.js
> @@ -10,6 +10,11 @@ Ext.define('PVE.sdn.zones.EvpnInputPanel', {
> values.type = me.type;
> }
>
> + if (values['exitnodes-primary'] === '') {
> + delete values['exitnodes-primary'];
> + values.delete.push('exitnodes-primary');
> + }
> +
> return values;
> },
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH frr] bump version to 8.5.4-1+pve1
Signed-off-by: Alexandre Derumier --- debian/changelog | 8 frr | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index e630dba..c37526d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +frr (8.5.4-1+pve1) bookworm; urgency=medium + + * update upstream sources to current stable/8.4 (commit +24f1d450f57321130b75ff55179c19e67ffcc572) fixing among other things: +- fix nexthop gateway out of sync between zebra and kernel + + -- Proxmox Support Team Wed, 22 Feb 2024 15:10:01 +0200 + frr (8.5.2-1+pve1) bookworm; urgency=medium * update upstream sources to current stable/8.5 (commit diff --git a/frr b/frr index 1622c2e..24f1d45 16 --- a/frr +++ b/frr @@ -1 +1 @@ -Subproject commit 1622c2ece2f68e034b43fb037503514c2195aba5 +Subproject commit 24f1d450f57321130b75ff55179c19e67ffcc572 -- 2.39.2 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] sdn: evpn: allow empty primary exit node in zone form
--- Begin Message --- Message initial De: Stefan Hanreich >>This was broken when adding a new EVPN zone and there's an easier way >>built-in to our widget toolkit. I've taken the liberty of sending a v2 >>and mentioning you [1]. Oh, great, thanks ! I was banging my head to find a clean way to fix it :) --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
