[pve-devel] applied: [PATCH proxmox-i18n] update fr.po
On 1/10/20 1:45 AM, Alexandre Derumier wrote: > Signed-off-by: Alexandre Derumier > --- > fr.po | 325 +++--- > 1 file changed, 107 insertions(+), 218 deletions(-) > applied, much thanks! ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network] vlan/qinq: use vlan-raw-device to support long predictable interfaces name
users have reported in the forum some crazy long interfaces names
like "enp0s20f0u8u2c2".
So they are no space for create a "enp0s20f0u8u2c2.vlan".
Signed-off-by: Alexandre Derumier
---
PVE/Network/SDN/Zones/QinQPlugin.pm | 18 --
PVE/Network/SDN/Zones/VlanPlugin.pm | 8
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/PVE/Network/SDN/Zones/QinQPlugin.pm
b/PVE/Network/SDN/Zones/QinQPlugin.pm
index d36f0d8..1a6edf0 100644
--- a/PVE/Network/SDN/Zones/QinQPlugin.pm
+++ b/PVE/Network/SDN/Zones/QinQPlugin.pm
@@ -52,18 +52,24 @@ sub generate_sdn_config {
my $iface =
PVE::Network::SDN::Zones::Plugin::get_uplink_iface($interfaces_config, $uplink);
-$iface .= ".$zone_tag";
-
-#tagged interface
+#service vlan
my @iface_config = ();
+push @iface_config, "vlan-raw-device $iface";
+push @iface_config, "vlan-id $zone_tag";
push @iface_config, "vlan-protocol $vlanprotocol" if $vlanprotocol;
push @iface_config, "mtu $mtu" if $mtu;
-push(@{$config->{$iface}}, @iface_config) if !$config->{$iface};
+push(@{$config->{"qinq$zoneid"}}, @iface_config) if !$config->{$iface};
+
+#customer vlan
+my @iface_config = ();
+push @iface_config, "vlan-raw-device qinq$zoneid";
+push @iface_config, "vlan-id $tag";
+push @iface_config, "mtu $mtu" if $mtu;
+push(@{$config->{"vlan$vnetid"}}, @iface_config) if !$config->{$iface};
-$iface .= ".$tag";
#vnet bridge
@iface_config = ();
-push @iface_config, "bridge_ports $iface";
+push @iface_config, "bridge_ports vlan$vnetid";
push @iface_config, "bridge_stp off";
push @iface_config, "bridge_fd 0";
push @iface_config, "mtu $mtu" if $mtu;
diff --git a/PVE/Network/SDN/Zones/VlanPlugin.pm
b/PVE/Network/SDN/Zones/VlanPlugin.pm
index 63db8ab..af76b43 100644
--- a/PVE/Network/SDN/Zones/VlanPlugin.pm
+++ b/PVE/Network/SDN/Zones/VlanPlugin.pm
@@ -50,16 +50,16 @@ sub generate_sdn_config {
my $iface =
PVE::Network::SDN::Zones::Plugin::get_uplink_iface($interfaces_config, $uplink);
-$iface .= ".$tag";
-
#tagged interface
my @iface_config = ();
push @iface_config, "mtu $mtu" if $mtu;
-push(@{$config->{$iface}}, @iface_config) if !$config->{$iface};
+push @iface_config, "vlan-raw-device $iface";
+push @iface_config, "vlan-id $tag";
+push(@{$config->{"vlan$vnetid"}}, @iface_config) if !$config->{$iface};
#vnet bridge
@iface_config = ();
-push @iface_config, "bridge_ports $iface";
+push @iface_config, "bridge_ports vlan$vnetid";
push @iface_config, "bridge_stp off";
push @iface_config, "bridge_fd 0";
push @iface_config, "mtu $mtu" if $mtu;
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 proxmox-widget-toolkit 1/2] networkedit: bond: add bond-primary field
Signed-off-by: Alexandre Derumier
---
node/NetworkEdit.js | 16
1 file changed, 16 insertions(+)
diff --git a/node/NetworkEdit.js b/node/NetworkEdit.js
index c3ef63c..ca0011f 100644
--- a/node/NetworkEdit.js
+++ b/node/NetworkEdit.js
@@ -110,6 +110,13 @@ Ext.define('Proxmox.node.NetworkEdit', {
disabled: true
});
+ var primaryfield = Ext.createWidget('textfield', {
+ fieldLabel: gettext('bond-primary'),
+ name: 'bond-primary',
+ value: '',
+ disabled: true
+ });
+
column2.push({
xtype: 'bondModeSelector',
fieldLabel: gettext('Mode'),
@@ -120,9 +127,17 @@ Ext.define('Proxmox.node.NetworkEdit', {
if (value === 'balance-xor' ||
value === '802.3ad') {
policySelector.setDisabled(false);
+ primaryfield.setDisabled(true);
+ primaryfield.setValue('');
+ } else if (value === 'active-backup') {
+ primaryfield.setDisabled(false);
+ policySelector.setDisabled(true);
+ policySelector.setValue('');
} else {
policySelector.setDisabled(true);
policySelector.setValue('');
+ primaryfield.setDisabled(true);
+ primaryfield.setValue('');
}
}
},
@@ -130,6 +145,7 @@ Ext.define('Proxmox.node.NetworkEdit', {
});
column2.push(policySelector);
+ column2.push(primaryfield);
} else if (me.iftype === 'OVSBond') {
column2.push({
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 proxmox-widget-toolkit 2/2] networkedit: add mtu field
Signed-off-by: Alexandre Derumier
---
node/NetworkEdit.js | 8
1 file changed, 8 insertions(+)
diff --git a/node/NetworkEdit.js b/node/NetworkEdit.js
index ca0011f..ce7e7ae 100644
--- a/node/NetworkEdit.js
+++ b/node/NetworkEdit.js
@@ -250,6 +250,14 @@ Ext.define('Proxmox.node.NetworkEdit', {
fieldLabel: gettext('Gateway') + ' (IPv6)',
vtype: 'IP6Address',
name: 'gateway6'
+ },
+ {
+ xtype: 'proxmoxintegerfield',
+ minValue: 1280,
+ maxValue: 65520,
+ deleteEmpty: !me.isCreate,
+ fieldLabel: 'MTU',
+ name: 'mtu'
}
);
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 proxmox-widget-toolkit 0/2] local network config improvements
Following pve-common serie Changelog v2: fix mtu field Alexandre Derumier (2): networkedit: bond: add bond-primary field networkedit: add mtu field node/NetworkEdit.js | 24 1 file changed, 24 insertions(+) -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH proxmox-i18n] update fr.po
Signed-off-by: Alexandre Derumier --- fr.po | 325 +++--- 1 file changed, 107 insertions(+), 218 deletions(-) diff --git a/fr.po b/fr.po index b7d9e52..7fc46f8 100644 --- a/fr.po +++ b/fr.po @@ -130,19 +130,16 @@ msgstr "Ajouter l'entête TLS recue" #: pve-manager/www/manager6/ceph/FS.js:49 #: pve-manager/www/manager6/ceph/Pool.js:53 -#, fuzzy msgid "Add as Storage" -msgstr "Ajouter Stockage" +msgstr "Ajouter comme Stockage" #: pve-manager/www/manager6/ceph/FS.js:54 -#, fuzzy msgid "Add the new CephFS to the cluster storage configuration." -msgstr "Information du Cluster" +msgstr "Ajouter le nouveau CephFS à la configuration du cluster de stockage" #: pve-manager/www/manager6/ceph/Pool.js:58 -#, fuzzy msgid "Add the new pool to the cluster storage configuration." -msgstr "Information du Cluster" +msgstr "Ajouter le nouveau pool à la configuration du cluster de stockage" #: pve-manager/www/manager6/ceph/CephInstallWizard.js:224 msgid "" @@ -230,14 +227,12 @@ msgid "Apply" msgstr "Appliquer" #: proxmox-widget-toolkit/node/NetworkView.js:130 -#, fuzzy msgid "Apply Configuration" -msgstr "Configuration" +msgstr "Appliquer la configuration" #: pmg-gui/js/SpamDetectorCustom.js:84 pmg-gui/js/SpamDetectorCustom.js:251 -#, fuzzy msgid "Apply Custom Scores" -msgstr "Scores de spam" +msgstr "Appliquer les scores personnalisés" #: pve-manager/www/manager6/lxc/Options.js:56 msgid "Architecture" @@ -288,9 +283,8 @@ msgid "Attach orig. Mail" msgstr "Joindre le courriel original" #: pmg-gui/js/AttachmentQuarantine.js:95 pmg-gui/js/NavigationTree.js:110 -#, fuzzy msgid "Attachment Quarantine" -msgstr "Quarantaine de Spam" +msgstr "Quarantaine de pièce jointe" #: pve-manager/www/manager6/node/Disks.js:269 msgid "Attribute" @@ -300,9 +294,8 @@ msgstr "Attributs" #: pve-manager/www/manager6/qemu/AudioEdit.js:44 #: pve-manager/www/manager6/qemu/HardwareView.js:292 #: pve-manager/www/manager6/qemu/HardwareView.js:702 -#, fuzzy msgid "Audio Device" -msgstr "Device" +msgstr "Périphérique Audio" #: pmg-gui/js/Utils.js:21 msgid "Auditor" @@ -323,13 +316,12 @@ msgstr "Générer automatiquement les propriétés unique, p. ex. adresses MAC" #: pve-manager/www/manager6/ceph/OSD.js:71 #: pve-manager/www/manager6/ceph/OSD.js:107 #: pve-manager/www/manager6/qemu/Options.js:302 -#, fuzzy msgid "Automatic" -msgstr "Démarrage automatique" +msgstr "Automatique" #: pve-manager/www/manager6/qemu/Options.js:312 msgid "Automatic (Storage used by the VM, or 'local')" -msgstr "" +msgstr "Automatique (Stoackage utilisé par la VM, ou 'local'" #: proxmox-widget-toolkit/node/NetworkEdit.js:49 #: proxmox-widget-toolkit/node/NetworkView.js:341 @@ -386,9 +378,8 @@ msgid "Backup Job" msgstr "Tâche de sauvegarde" #: pve-manager/www/manager6/dc/OptionView.js:182 -#, fuzzy msgid "Backup Restore" -msgstr "Tâche de sauvegarde" +msgstr "Sauvegarde Restauration" #: pve-manager/www/manager6/grid/BackupView.js:120 msgid "Backup now" @@ -407,7 +398,6 @@ msgid "Bandwidth Limit" msgstr "Limite de bande passante" #: pve-manager/www/manager6/dc/OptionView.js:166 -#, fuzzy msgid "Bandwidth Limits" msgstr "Limite de bande passante" @@ -448,18 +438,16 @@ msgid "Block Size" msgstr "Taille des blocs" #: pmg-gui/js/VirusDetectorOptions.js:11 -#, fuzzy msgid "Block encrypted archives and documents" -msgstr "Bloquer archives chiffrées" +msgstr "Bloquer archives et documents chiffrés" #: pmg-gui/js/Utils.js:515 msgid "Body" msgstr "Corps" #: proxmox-widget-toolkit/node/NetworkView.js:365 -#, fuzzy msgid "Bond Mode" -msgstr "Mode" +msgstr "Bond Mode" #: pve-manager/www/manager6/qemu/BootOrderEdit.js:159 #: pve-manager/www/manager6/qemu/Options.js:91 @@ -540,9 +528,8 @@ msgstr "Lecteur CD/DVD" #: proxmox-widget-toolkit/form/NetworkSelector.js:95 #: proxmox-widget-toolkit/node/NetworkView.js:391 -#, fuzzy msgid "CIDR" -msgstr "IP/CIDR" +msgstr "CIDR" #: pmg-gui/js/Dashboard.js:412 pve-manager/www/manager6/Utils.js:254 #: pve-manager/www/manager6/dc/Summary.js:37 @@ -650,9 +637,8 @@ msgid "Check" msgstr "Vérifier" #: pve-manager/www/manager6/qemu/USBEdit.js:80 -#, fuzzy msgid "Choose Device" -msgstr "Périphérique PCI" +msgstr "Choississez un périphérique" #: pve-manager/www/manager6/qemu/USBEdit.js:99 msgid "Choose Port" @@ -838,9 +824,8 @@ msgid "Configuration" msgstr "Configuration" #: pve-manager/www/manager6/ceph/Config.js:140 -#, fuzzy msgid "Configuration Database" -msgstr "Configuration" +msgstr "Base de données de Configuration" #: pve-manager/www/manager6/Utils.js:907 msgid "Configuration Unsupported" @@ -1071,19 +1056,16 @@ msgid "Custom Rule Score" msgstr "" #: pmg-gui/js/SpamDetectorConfiguration.js:28 -#, fuzzy msgid "Custom Scores" -msgstr "Scores de spam" +msgstr "Scores Personnalisés" #: pve-manager/www/manager6/ceph/OSD.js:51 -#, fuzzy msgid "DB Disk" -msgstr "Disque" +msgstr "Disque DB"
[pve-devel] [PATCH dab-pve-appliances v2] pmg: optionally verify cvd files with sigtool
sigtool (1) is clamav's utility to manipulate and verify cvd files.
It is shipped in the clamav package, which is not installed inside
pmg (pmg uses the daemonized version - clamav-daemon).
This patch verifies the downloaded cvd-files if sigtool is installed on the
build host and skips the verification if not (in order to not depend on an
installed clamav package).
Signed-off-by: Stoiko Ivanov
---
v1 -> v2
* changed the check for sigtool's existence to the posix compatible
`command -v $cmd` instead of relying on hardcoded paths (and not using them
during the actual invocation) - Thanks @Thomas for spotting and suggesting
this!
debian-10.0-pmg-64/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian-10.0-pmg-64/Makefile b/debian-10.0-pmg-64/Makefile
index 0e6efff..d12b4f4 100644
--- a/debian-10.0-pmg-64/Makefile
+++ b/debian-10.0-pmg-64/Makefile
@@ -33,3 +33,4 @@ dist-clean:
${CVD_FILES}:
curl -L --silent --show-error --fail --time-cond $@ -o $@.tmp
http://database.clamav.net/$@
[ -f $@.tmp ] && mv $@.tmp $@ || true
+ if command -v sigtool > /dev/null ; then sigtool -i $@; else echo
"skipping verification of $@"; fi
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ceph 1/2] fix Ceph version string handling
Hello Martin, On Thu, Jan 09, 2020 at 02:23:07PM +0100, Martin Verges wrote: > Hello Thomas, > > 1. we provide 14.2.5, the latest stable release available (we have upcoming > > 14.2.6 already on track) > > > > Good to know, does not seem to be a knowledge that some proxmox users have > nor was it the case in the past. I hope this knowledge spreads (it's hardly hidden). ;) A good point to start from is the release notes and our documentation [0]. I guess the past needs a little clarification (Debian Stretch + Mimic), Fabian had a discussion upstream [1]. And as there was no supported way to build available. We decided at this point to not burden our users with an experimental build of Ceph. Which would also have changed fundamental parts of the OS (eg. glibc). > > > > If you have custom patches which improve the experience I'd suggest > > up-streaming them to Ceph or, if they affect our management tooling for > > ceph, telling us here or at bugzilla.proxmox.com and/or naturally > > up-streaming them to PVE. > > > > As a founding member of the Ceph foundation, we always provide all patches > to the Ceph upstream and as always they will be included in future releases > of Ceph or backported to older versions. Thanks. > > The Ceph integration from a client perspective should work as with every > > other > > "external" ceph server setup. IMO, it makes no sense to mix our management > > interface for Ceph with externally untested builds. We sync releases of > > Ceph > > on our side with releases of the management stack, that would be > > circumvented > > completely, as would be the testing of the Ceph setup. > > > > If people want to use croit that's naturally fine for us, they can use the > > croit managed ceph cluster within PVE instances as RBD or CephFS client > > just > > fine, as it is and was always the case. But, mixing croit packages with PVE > > management makes not much sense to me, I'm afraid. > > > > I agree that user should stick to the versions a vendor provides, in your > case the proxmox Ceph versions. But as I already wrote, we get a lot of > proxmox users on our table that use proxmox and Ceph and some seem to have > an issue. I urge those users to also speak to us. If we don't know about possible issues, then we can't help. > > As my fix does not affect any proxmox functionality in a negative way, no > will it break anything. Why would you hesitate to allow users to choose the > Ceph versions of their liking? It just enables proxmox to don't break on > such versions. Proxmox VE's Ceph management is written explicitly for the hyper-converged use case. This intent binds the management of Ceph to the Proxmox VE clustered nodes and not to a separate Ceph cluster. We provide packages specifically tested on Proxmox VE. And for its use case, as Ceph client or cluster (RBD/CephFS services). As user, using packages provided by a third party circumvents our testing, possibly breaks usage (e.g., API/CLI changes) and in the end, the user may be left with an installation in an unknown state. When you use Proxmox VE as a client, the dashboard (or CLI) should not be used. Only due to the nature of Ceph's commands, some functionality is working on the dashboard. For sure, this separation could be made more visible. I hopefully this explains, why we are currently against applying this patch of yours. -- Cheers, Alwin [0] https://pve.proxmox.com/wiki/Roadmap https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysadmin_package_repositories_ceph https://pve.proxmox.com/pve-docs/chapter-pveceph.html [1] http://lists.ceph.com/pipermail/ceph-users-ceph.com/2018-June/027366.html ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server] qemu_block_resize: align size to 512
On 1/9/20 11:20 AM, Fabian Ebner wrote:
> Doing 'qm resize 111 scsi0 +0.2G' where scsi0 is a qcow2 disk
> produced the following errors:
> "VM 111 qmp command 'block_resize' failed - The new size must be a multiple
> of 512"
> if the VM is running and
> "qemu-img: The new size must be a multiple of 512"
has it to be 512, or is this actually related to the qcow2 cluster_size,
which by default is 512? More out of interest, as we do not alter that
currently.
> if the VM isn't running
>
> Signed-off-by: Fabian Ebner
> ---
> PVE/QemuServer.pm | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 2b68d81..2c92c3b 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -4668,6 +4668,10 @@ sub qemu_block_resize {
>
> my $running = check_running($vmid);
>
> +# aligning to 512 is required for qcow2 disks
but this is called for all backing image types, not only qcow2??
> +my $padding = (512 - $size % 512) % 512;
> +$size = $size + $padding;
> +
> $size = 0 if !PVE::Storage::volume_resize($storecfg, $volid, $size,
> $running);
why not move the padding adjustment into the storage plugins volume_resize
implementation using qcow2? I.e., the base Plugin's version.
Also, is this a problem with other backing types? (RBD, ZFS?) The RBD
volume_resize
seems a bit fishy, as it does a plain ($size/1024/1024) - could that result in
truncation? Why does it allows shrinkage is also a question..
>
> return if !$running;
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH qemu-server] Remove unused 'sharedvm' variable
On 1/9/20 10:23 AM, Fabian Ebner wrote:
> AFAICT this one hasn't been in use since commit
> '4530494bf9f3d45c4a405c53ef3688e641f6bd8e'
>
> Signed-off-by: Fabian Ebner
> ---
> PVE/QemuMigrate.pm | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
> index 0353458..49848e8 100644
> --- a/PVE/QemuMigrate.pm
> +++ b/PVE/QemuMigrate.pm
> @@ -282,8 +282,6 @@ sub sync_disks {
> my $other_errors = [];
> my $abort = 0;
>
> - my $sharedvm = 1;
> -
> my $log_error = sub {
> my ($msg, $volid) = @_;
>
> @@ -310,7 +308,6 @@ sub sync_disks {
>
> # check if storage is available on target node
> PVE::Storage::storage_check_node($self->{storecfg}, $targetsid,
> $self->{node});
> - $sharedvm = 0; # there is a non-shared disk
>
> PVE::Storage::foreach_volid($dl, sub {
> my ($volid, $sid, $volname) = @_;
> @@ -352,8 +349,6 @@ sub sync_disks {
>
> return if $scfg->{shared};
>
> - $sharedvm = 0;
> -
> $local_volumes->{$volid}->{ref} = $attr->{referenced_in_config} ?
> 'config' : 'snapshot';
>
> if ($attr->{cdrom}) {
>
applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH manager] fix #2334: gui/cloudinit: enable edit button only when editor is set
On 1/9/20 9:59 AM, Dominik Csapak wrote:
> when a user does not have the right privileges for cloudinit (e.g.
> VM.Config.Network), we do not set an editor, which results in a button
> that does nothing when pressed
>
> fix this by enabling the button only when there is an editor set
>
> Signed-off-by: Dominik Csapak
> ---
> www/manager6/qemu/CloudInit.js | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/www/manager6/qemu/CloudInit.js b/www/manager6/qemu/CloudInit.js
> index cb4742e5..cbb4af9d 100644
> --- a/www/manager6/qemu/CloudInit.js
> +++ b/www/manager6/qemu/CloudInit.js
> @@ -65,6 +65,10 @@ Ext.define('PVE.qemu.CloudInit', {
> {
> xtype: 'proxmoxButton',
> disabled: true,
> + enableFn: function(rec) {
> + let me = this.up('pveCiPanel');
> + return !!me.rows[rec.data.key].editor;
> + },
> handler: function() {
> var me = this.up('grid');
> me.run_editor();
>
applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH V2 ifupdown2 3/3] bump 2.0.1-1+pve1
On 1/9/20 12:23 PM, Alexandre Derumier wrote: > Signed-off-by: Alexandre Derumier > --- > debian/changelog | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/debian/changelog b/debian/changelog > index bb44795..ff33f67 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,9 @@ > +ifupdown2 (2.0.1-1+pve1) pve; urgency=medium > + > + * Bump to 2.0.1 > + > + -- Proxmox Support Team Tue, 6 Jan 2020 12:24:12 > +0100 > + > ifupdown2 (1.2.8-1+pve4) pve; urgency=medium > >* add arp-accept option required for bgp-evpn > applied, but squashed minor wording changes into it, just FYI. Thanks! ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH V2 ifupdown2 1/3] update patches
On 1/9/20 12:23 PM, Alexandre Derumier wrote:
> remove add-uplink-id-option.patch (not needed),
> remove arp-accept option patch (available upstream)
> remove debian-fixup-networking.service.patch (new @ifup service upstream)
>
> rebase others patches
>
> Signed-off-by: Alexandre Derumier
> ---
> ...-veth-fwpr-interfaces-from-bridge-on.patch | 44 +
> ...add-dummy-mtu-bridgevlanport-modules.patch | 11 ++--
> ...subinterface-in-a-vlan-aware-bridge.patch} | 11 ++--
> ...0003-debian-fixup-networking.service.patch | 64 ---
> ...ridge-is-tap-veth-are-still-plugged.patch} | 11 ++--
> ...vxlan-interfaces-when-ifreload_down.patch} | 11 ++--
> .../pve/0006-add-uplink-id-option.patch | 27
> ...-tuning.patch => 0006-config-tuning.patch} | 8 +--
> .../pve/0009-add-arp-accept-option.patch | 55
> debian/patches/series | 11 ++--
> 10 files changed, 66 insertions(+), 187 deletions(-)
> rename
> debian/patches/pve/{0004-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch
> => 0003-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch} (86%)
> delete mode 100644
> debian/patches/pve/0003-debian-fixup-networking.service.patch
> rename
> debian/patches/pve/{0005-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch
> => 0004-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch} (86%)
> rename
> debian/patches/pve/{0007-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch
> => 0005-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch} (85%)
> delete mode 100644 debian/patches/pve/0006-add-uplink-id-option.patch
> rename debian/patches/pve/{0008-config-tuning.patch =>
> 0006-config-tuning.patch} (82%)
> delete mode 100644 debian/patches/pve/0009-add-arp-accept-option.patch
>
applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 cluster 4/4] Add cluster join API version check
Adds API call GET /cluster/config/apiversion to retrieve remote clusters
join-API version (0 is assumed for versions without this endpoint). Also
available via CLI as 'pvecm apiver'.
Introduce API_AGE similar to storage plugin API, but with two ages for
cluster/joinee roles. Currently, all versions are intercompatible.
For future usage, a new 'addnode' parameter 'apiversion' is introduced,
to allow introducing API breakages for joining nodes as well.
As a first compatibility check, use new fallback method only if
available. This ensures full compatibility between nodes/clusters with
and without new fallback behaviour.
Signed-off-by: Stefan Reiter
---
I do think that both AS_CLUSTER and AS_JOINEE ages are necessary indeed:
* AS_CLUSTER: If we introduce a parameter to addnode that we cannot have a
fallback for, and old versions don't provide it, we can exclude them from
joining
* AS_JOINEE: If something changes regarding the cluster joing procedure and we
know that older versions cannot correctly add us to the cluster, we can abort
the join
If I'm wrong, it'd be easy enough to remove one or the other. Having both
doesn't hurt though?
data/PVE/API2/ClusterConfig.pm | 37 +-
data/PVE/CLI/pvecm.pm | 22 +++-
data/PVE/Cluster/Setup.pm | 23 -
3 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/data/PVE/API2/ClusterConfig.pm b/data/PVE/API2/ClusterConfig.pm
index e6b59cf..205252f 100644
--- a/data/PVE/API2/ClusterConfig.pm
+++ b/data/PVE/API2/ClusterConfig.pm
@@ -58,11 +58,33 @@ __PACKAGE__->register_method({
{ name => 'totem' },
{ name => 'join' },
{ name => 'qdevice' },
+ { name => 'apiversion' },
];
return $result;
}});
+__PACKAGE__->register_method ({
+name => 'join_api_version',
+path => 'apiversion',
+method => 'GET',
+description => "Return the version of the cluster join API available on
this node.",
+permissions => {
+ check => ['perm', '/', [ 'Sys.Audit' ]],
+},
+parameters => {
+ additionalProperties => 0,
+ properties => {},
+},
+returns => {
+ type => 'integer',
+ minimum => 0,
+ description => "Cluster Join API version, currently " .
PVE::Cluster::Setup::JOIN_API_VERSION,
+},
+code => sub {
+ return PVE::Cluster::Setup::JOIN_API_VERSION;
+}});
+
__PACKAGE__->register_method ({
name => 'create',
path => '',
@@ -213,6 +235,11 @@ __PACKAGE__->register_method ({
format => 'ip',
optional => 1,
},
+ apiversion => {
+ type => 'integer',
+ description => 'The JOIN_API_VERSION of the new node.',
+ optional => 1,
+ },
}),
},
returns => {
@@ -235,6 +262,14 @@ __PACKAGE__->register_method ({
code => sub {
my ($param) = @_;
+ $param->{apiversion} //= 0;
+ if ($param->{apiversion} < (PVE::Cluster::Setup::JOIN_API_VERSION -
+ PVE::Cluster::Setup::JOIN_API_AGE_AS_CLUSTER)) {
+ die "unsupported old API version on joining node
($param->{apiversion},"
+ . " cluster node has " . PVE::Cluster::Setup::JOIN_API_VERSION
+ . "), please upgrade before joining\n";
+ }
+
PVE::Cluster::check_cfs_quorum();
my $vc_errors;
@@ -291,7 +326,7 @@ __PACKAGE__->register_method ({
# FIXME: remove in 8.0 or when joining an old node not supporting
# new_node_ip becomes infeasible otherwise
my $legacy_fallback = 0;
- if (!$param->{new_node_ip} && scalar(%$links) == 1) {
+ if (!$param->{new_node_ip} && scalar(%$links) == 1 &&
$param->{apiversion} == 0) {
my $passed_link_id = (keys %$links)[0];
my $passed_link = delete $links->{$passed_link_id};
$param->{new_node_ip} = $passed_link->{address};
diff --git a/data/PVE/CLI/pvecm.pm b/data/PVE/CLI/pvecm.pm
index a838ff2..3ce80a6 100755
--- a/data/PVE/CLI/pvecm.pm
+++ b/data/PVE/CLI/pvecm.pm
@@ -390,6 +390,20 @@ __PACKAGE__->register_method ({
run_command($cmd, 'outfunc' => sub {}, 'errfunc' => sub {},
'errmsg' => "unable to copy ssh ID");
+ $cmd = ['ssh', $host, '-o', 'BatchMode=yes', 'pvecm', 'apiver'];
+ my $remote_apiver = 0;
+ run_command($cmd, 'outfunc' => sub {
+ $remote_apiver = shift;
+ chomp $remote_apiver;
+ }, 'noerr' => 1);
+
+ if ($remote_apiver < (PVE::Cluster::Setup::JOIN_API_VERSION -
+ PVE::Cluster::Setup::JOIN_API_AGE_AS_JOINEE)) {
+ die "error: incompatible join API version on cluster
($remote_apiver,"
+ . " local has " . PVE::Cluster::Setup::JOIN_API_VERSION .
"). Make"
+ . " sure all
[pve-devel] [PATCH v3 cluster 1/4] corosync: add verify_conf
It does some basic sanity checking, warns the user about encryption
settings and unresolved hostnames, and finally makes sure that all nodes
have the same links configured (as well as comparing the configured
links to specified interfaces, if there are any).
A corosync.conf that has been created and modified strictly through our
API should *always* be valid.
verify_conf is called in 'addnode', warnings and errors are returned via
the API to be displayed in the task log of the node asking to join. If a
verification error occurs, it is handled specially via a "raise" outside
of any lock code that strips extra information from an Exception
instance. This ensures that multi-line formatted errors can be returned.
Warnings are always returned as array, to be printed on the caller.
Includes testing.
Signed-off-by: Stefan Reiter
---
data/PVE/API2/ClusterConfig.pm| 40 ++-
data/PVE/Cluster/Setup.pm | 23 +-
data/PVE/Corosync.pm | 116 +-
data/test/corosync_parser_test.pl | 29
4 files changed, 205 insertions(+), 3 deletions(-)
diff --git a/data/PVE/API2/ClusterConfig.pm b/data/PVE/API2/ClusterConfig.pm
index c426a30..e05fd55 100644
--- a/data/PVE/API2/ClusterConfig.pm
+++ b/data/PVE/API2/ClusterConfig.pm
@@ -3,6 +3,7 @@ package PVE::API2::ClusterConfig;
use strict;
use warnings;
+use PVE::Exception;
use PVE::Tools;
use PVE::SafeSyslog;
use PVE::RESTHandler;
@@ -219,7 +220,13 @@ __PACKAGE__->register_method ({
},
corosync_conf => {
type => 'string',
- }
+ },
+ warnings => {
+ type => 'array',
+ items => {
+ type => 'string',
+ },
+ },
},
},
code => sub {
@@ -227,11 +234,17 @@ __PACKAGE__->register_method ({
PVE::Cluster::check_cfs_quorum();
+ my $vc_errors;
+ my $vc_warnings;
+
my $code = sub {
my $conf = PVE::Cluster::cfs_read_file("corosync.conf");
my $nodelist = PVE::Corosync::nodelist($conf);
my $totem_cfg = PVE::Corosync::totem_config($conf);
+ ($vc_errors, $vc_warnings) = PVE::Corosync::verify_conf($conf);
+ die if scalar(@$vc_errors);
+
my $name = $param->{node};
# ensure we do not reuse an address, that can crash the whole
cluster!
@@ -317,11 +330,36 @@ __PACKAGE__->register_method ({
};
$config_change_lock->($code);
+
+ # If vc_errors is set, we died because of verify_conf.
+ # Raise this error, since it contains more information than just a
+ # single-line string.
+ if (defined($vc_errors) && scalar(@$vc_errors)) {
+ my $err_hash = {};
+ my $add_errs = sub {
+ my $type = shift;
+ my @arr = @_;
+ return if !scalar(@arr);
+
+ my %newhash = map { $type . $_ => $arr[$_] } 0..$#arr;
+ $err_hash = {
+ %$err_hash,
+ %newhash,
+ };
+ };
+
+ $add_errs->("warning", @$vc_warnings);
+ $add_errs->("error", @$vc_errors);
+
+ PVE::Exception::raise("invalid corosync.conf\n", errors =>
$err_hash);
+ }
+
die $@ if $@;
my $res = {
corosync_authkey => PVE::Tools::file_get_contents($authfile),
corosync_conf => PVE::Tools::file_get_contents($clusterconf),
+ warnings => $vc_warnings,
};
return $res;
diff --git a/data/PVE/Cluster/Setup.pm b/data/PVE/Cluster/Setup.pm
index f863885..b115d45 100644
--- a/data/PVE/Cluster/Setup.pm
+++ b/data/PVE/Cluster/Setup.pm
@@ -685,7 +685,28 @@ sub join {
$args->{link1} = $param->{link1} if defined($param->{link1});
print "Request addition of this node\n";
-my $res = $conn->post("/cluster/config/nodes/$nodename", $args);
+my $res = eval { $conn->post("/cluster/config/nodes/$nodename", $args); };
+if (my $err = $@) {
+ if (ref($err) && $err->isa('PVE::APIClient::Exception')) {
+ # we received additional info about the error, show the user
+ chomp $err->{msg};
+ warn "An error occured on the cluster node: $err->{msg}\n";
+ foreach my $key (sort keys %{$err->{errors}}) {
+ my $symbol = ($key =~ m/^warning/) ? '*' : '!';
+ warn "$symbol $err->{errors}->{$key}\n";
+ }
+
+ die "Cluster join aborted!\n";
+ }
+
+ die $@;
+}
+
+if (defined($res->{warnings})) {
+ foreach my $warn (@{$res->{warnings}}) {
+ warn "cluster: $warn\n";
+ }
+}
print "Join request OK, finishing setup locally\n";
diff --git a/data/PVE/Corosync.pm b/data/PVE/Corosync.pm
index 3208a6b..c69c8d8 100644
--- a/data/PVE/Corosync.pm
+++ b/data/PVE/Corosync.pm
@@ -15,6 +15,7 @@ use PVE::Tools;
use PVE::Tools qw($IPV4
[pve-devel] [PATCH v3 cluster 2/4] Enable support for up to 8 corosync links
add_corosync_link_properties/extract_corosync_link_args are introduced
as helpers to avoid hardcoding links in parameters=>properties on
several occasions, while still providing autocompletion with pvecm by
being seperate parameters instead of an array.
Maximum number of links is given as constant MAX_LINK_COUNT, should it
change in the future.
All necessary functions have been updated to
use the new $links array format instead of seperate $link0/$link1
parameters, and call sites changed accordingly.
Signed-off-by: Stefan Reiter
---
This patch intentionally removes some verification and fallback code to be
reintroduced in the next one.
data/PVE/API2/ClusterConfig.pm | 51 +++-
data/PVE/CLI/pvecm.pm | 21
data/PVE/Cluster/Setup.pm | 20
data/PVE/Corosync.pm | 88 +++---
4 files changed, 97 insertions(+), 83 deletions(-)
diff --git a/data/PVE/API2/ClusterConfig.pm b/data/PVE/API2/ClusterConfig.pm
index e05fd55..2c5bb03 100644
--- a/data/PVE/API2/ClusterConfig.pm
+++ b/data/PVE/API2/ClusterConfig.pm
@@ -68,10 +68,11 @@ __PACKAGE__->register_method ({
path => '',
method => 'POST',
protected => 1,
-description => "Generate new cluster configuration.",
+description => "Generate new cluster configuration. If no links given,"
+. " default to local IP address as link0.",
parameters => {
additionalProperties => 0,
- properties => {
+ properties => PVE::Corosync::add_corosync_link_properties({
clustername => {
description => "The name of the cluster.",
type => 'string', format => 'pve-node',
@@ -84,9 +85,7 @@ __PACKAGE__->register_method ({
minimum => 1,
optional => 1,
},
- link0 => get_standard_option('corosync-link'),
- link1 => get_standard_option('corosync-link'),
- },
+ }),
},
returns => { type => 'string' },
code => sub {
@@ -110,7 +109,7 @@ __PACKAGE__->register_method ({
my $nodename = PVE::INotify::nodename();
# get the corosync basis config for the new cluster
- my $config = PVE::Corosync::create_conf($nodename, %$param);
+ my $config = PVE::Corosync::create_conf($nodename, $param);
print "Writing corosync config to /etc/pve/corosync.conf\n";
PVE::Corosync::atomic_write_conf($config);
@@ -194,7 +193,7 @@ __PACKAGE__->register_method ({
description => "Adds a node to the cluster configuration. This call is for
internal use.",
parameters => {
additionalProperties => 0,
- properties => {
+ properties => PVE::Corosync::add_corosync_link_properties({
node => get_standard_option('pve-node'),
nodeid => get_standard_option('corosync-nodeid'),
votes => {
@@ -208,9 +207,7 @@ __PACKAGE__->register_method ({
description => "Do not throw error if node already exists.",
optional => 1,
},
- link0 => get_standard_option('corosync-link'),
- link1 => get_standard_option('corosync-link'),
- },
+ }),
},
returns => {
type => "object",
@@ -256,7 +253,7 @@ __PACKAGE__->register_method ({
while (my ($k, $v) = each %$nodelist) {
next if $k eq $name; # allows re-adding a node if force is
set
- for my $linknumber (0..1) {
+ for my $linknumber (0..PVE::Corosync::MAX_LINK_INDEX) {
my $id = "ring${linknumber}_addr";
next if !defined($v->{$id});
@@ -266,20 +263,10 @@ __PACKAGE__->register_method ({
}
};
- my $link0 = PVE::Corosync::parse_corosync_link($param->{link0});
- my $link1 = PVE::Corosync::parse_corosync_link($param->{link1});
-
- $check_duplicate_addr->($link0);
- $check_duplicate_addr->($link1);
-
- # FIXME: handle all links (0-7), they're all independent now
- $link0->{address} //= $name if exists($totem_cfg->{interface}->{0});
-
- die "corosync: using 'link1' parameter needs a interface with
linknumber '1' configured!\n"
- if $link1 && !defined($totem_cfg->{interface}->{1});
-
- die "corosync: totem interface with linknumber 1 configured but
'link1' parameter not defined!\n"
- if defined($totem_cfg->{interface}->{1}) && !defined($link1);
+ my $links = PVE::Corosync::extract_corosync_link_args($param);
+ foreach my $link (values %$links) {
+ $check_duplicate_addr->($link);
+ }
if (defined(my $res = $nodelist->{$name})) {
$param->{nodeid} = $res->{nodeid} if !$param->{nodeid};
@@ -317,13 +304,15 @@ __PACKAGE__->register_method ({
warn $@ if $@;
$nodelist
[pve-devel] [PATCH v3 cluster 3/4] Add verification and fallback to cluster join/addnode
Verify that the config of the new node is valid and compatible with the
cluster (i.e. that the links for the new node match the currently
configured nodes).
Additionally, fallback is provided via a new parameter to addnode,
'new_node_ip'. Previously, fallback was handled on the joining node, by
setting it's local IP as 'link0', however, a cluster with only one link,
but numbered 1-7 is still valid, and a fallback is possible, but the old
code would now fail.
Instead, pass the locally resolved IP via a seperate parameter
(resolving the IP on the cluster side is impractical, as IP resolution
could fail or provide a wrong IP for Corosync).
For compatibility reasons, allow fallback to occur via the old
method as well, but mark with FIXME for future removal.
Fallback fails in case the cluster has more than one link, in this case
only the user can know which NIC/IP corresponds to which cluster link.
Signed-off-by: Stefan Reiter
---
data/PVE/API2/ClusterConfig.pm | 63 +-
data/PVE/CLI/pvecm.pm | 7
data/PVE/Cluster/Setup.pm | 7
3 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/data/PVE/API2/ClusterConfig.pm b/data/PVE/API2/ClusterConfig.pm
index 2c5bb03..e6b59cf 100644
--- a/data/PVE/API2/ClusterConfig.pm
+++ b/data/PVE/API2/ClusterConfig.pm
@@ -207,6 +207,12 @@ __PACKAGE__->register_method ({
description => "Do not throw error if node already exists.",
optional => 1,
},
+ new_node_ip => {
+ type => 'string',
+ description => "IP Address of node to add. Used as fallback if
no links are given.",
+ format => 'ip',
+ optional => 1,
+ },
}),
},
returns => {
@@ -268,6 +274,59 @@ __PACKAGE__->register_method ({
$check_duplicate_addr->($link);
}
+ # Make sure that the newly added node has links compatible with the
+ # rest of the cluster. To start, extract all links that currently
+ # exist. Check any node, all have the same links here (because of
+ # verify_conf above).
+ my $node_options = (values %$nodelist)[0];
+ my $cluster_links = {};
+ foreach my $opt (keys %$node_options) {
+ my ($linktype, $linkid) = PVE::Corosync::parse_link_entry($opt);
+ next if !defined($linktype);
+ $cluster_links->{$linkid} = $node_options->{$opt};
+ }
+
+ # in case no fallback IP was passed, but instead only a single link,
+ # treat it as fallback to allow link-IDs to be matched automatically
+ # FIXME: remove in 8.0 or when joining an old node not supporting
+ # new_node_ip becomes infeasible otherwise
+ my $legacy_fallback = 0;
+ if (!$param->{new_node_ip} && scalar(%$links) == 1) {
+ my $passed_link_id = (keys %$links)[0];
+ my $passed_link = delete $links->{$passed_link_id};
+ $param->{new_node_ip} = $passed_link->{address};
+ $legacy_fallback = 1;
+ }
+
+ if (scalar(%$links)) {
+ # verify specified links exist and none are missing
+ for my $linknum (0..PVE::Corosync::MAX_LINK_INDEX) {
+ my $have_cluster_link = defined($cluster_links->{$linknum});
+ my $have_new_link = defined($links->{$linknum});
+
+ die "corosync: link $linknum exists in cluster config but
wasn't specified for new node\n"
+ if $have_cluster_link && !$have_new_link;
+ die "corosync: link $linknum specified for new node doesn't
exist in cluster config\n"
+ if !$have_cluster_link && $have_new_link;
+ }
+ } else {
+ # when called without any link parameters, fall back to
+ # new_node_ip, if all existing nodes only have a single link too
+ die "no links and no fallback ip (new_node_ip) given, cannot
join cluster\n"
+ if !$param->{new_node_ip};
+
+ my $cluster_link_count = scalar(%$cluster_links);
+ if ($cluster_link_count == 1) {
+ my $linknum = (keys %$cluster_links)[0];
+ $links->{$linknum} = { address => $param->{new_node_ip} };
+ } else {
+ die "cluster has $cluster_link_count links, but only 1
given"
+ if $legacy_fallback;
+ die "no links given but multiple links found on other
nodes,"
+ . " fallback only supported on single-link clusters\n";
+ }
+ }
+
if (defined(my $res = $nodelist->{$name})) {
$param->{nodeid} = $res->{nodeid} if !$param->{nodeid};
$param->{votes} = $res->{quorum_votes} if
!defined($param->{votes});
[pve-devel] [PATCH v3 0/4] Add support for up to 8 corosync links in API
This series allows the API to handle all 8 possible links that corosync 3 supports. Additional verifications are added to support a smarter fallback behaviour and abort join if the current cluster config is invalid or unsupported. verify_conf is not just nice-to-have, but required for patch 3 since it assumes all nodes to have the same links for the join verification to work. API/Backend only, frontend works with patched backend, but will not see any links other than 0 and 1. Last patch introduces a new join-API version concept, allowing to explicitly mark versions as incompatible during pre-join checks (roughly follows the storage plugin's API_AGE concept). This is also used to ensure compatibility between nodes that have this series applied, and ones that don't, in both directions (as joinee/cluster). v2 -> v3: * fix nits from Thomas' review (no more multi-line post-ifs ;) ) * fix fallback behaviour with single link specified and no new_node_ip * add helper for parsing ringX_addr entries * only add 'new_node_ip' parameters after introducing the join API to avoid breakage * improve error messages for verification and join API incompatibilities * document 'apiversion' return code better * add 'apiver' CLI call and use to verify version on SSH join * dropped 'IP check on cluster create' patch (previously 4/5) for now - was really tricky to rebase to the front, so I'll just send it seperately together with another semi-related minor change v1 -> v2: * improve verify_conf and related error/warning handling (changes from Fabians review) * rename MAX_LINK_COUNT -> MAX_LINK_INDEX * improve testing for verify_conf * fix \n usage in patch 4 (previously patch 5) * swapped path 4 <=> 5 to put API-version last, since technically optional and probably more discussion-worthy ;) * changed join-API concept to include two API ages (see patch 5 for more) - as discussed off-list with Thomas * rebase on master cluster: Stefan Reiter (4): corosync: add verify_conf Enable support for up to 8 corosync links Add verification and fallback to cluster join/addnode Add cluster join API version check data/PVE/API2/ClusterConfig.pm| 181 ++- data/PVE/CLI/pvecm.pm | 48 +-- data/PVE/Cluster/Setup.pm | 71 +-- data/PVE/Corosync.pm | 200 ++ data/test/corosync_parser_test.pl | 29 + 5 files changed, 448 insertions(+), 81 deletions(-) -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ceph 1/2] fix Ceph version string handling
hi, it seems you are missing our ceph repository[0] we only add it in case of a hyperconverged setup in that case our tools add the correct repositories to /etc/apt/sources.list.d/[1] kind regards 0: https://pve.proxmox.com/wiki/Package_Repositories#sysadmin_package_repositories_ceph 1: https://pve.proxmox.com/wiki/Manage_Ceph_Services_on_Proxmox_VE_Nodes#pve_ceph_install ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ceph 1/2] fix Ceph version string handling
Hello Thomas, I'm not sure how you can provided better and newer Ceph builds for Proxmox > VE > as: > 1. we provide 14.2.5, the latest stable release available (we have > upcoming 14.2.6 already on track) > Sorry to say, but my PVE hosts do not have Ceph 14.2.5 root@pve01 ~ $ apt-cache madison ceph ceph | 14.2.5-3 | http://ftp.de.debian.org/debian unstable/main amd64 Packages ceph | 12.2.11+dfsg1-2.1 | http://ftp.de.debian.org/debian buster/main amd64 Packages ceph | 12.2.11+dfsg1-2.1 | http://ftp.de.debian.org/debian testing/main amd64 Packages ceph | 12.2.11+dfsg1-2.1 | http://ftp.de.debian.org/debian buster/main Sources ceph | 12.2.11+dfsg1-2.1 | http://ftp.de.debian.org/debian testing/main Sources ceph | 12.2.11+dfsg1-2.1 | http://ftp.de.debian.org/debian unstable/main Sources ceph | 14.2.4-9 | http://ftp.de.debian.org/debian unstable/main Sources ceph | 14.2.5-3 | http://ftp.de.debian.org/debian unstable/main Sources root@pve02 ~ $ ceph -v ceph version 12.2.11 (26dc3775efc7bb286a1d6d66faee0ba30ea23eee) luminous (stable) Where do I get your builds from? -- Martin Verges Managing director Hint: Secure one of the last slots in the upcoming 4-day Ceph Intensive Training at https://croit.io/training/4-days-ceph-in-depth-training. Mobile: +49 174 9335695 E-Mail: martin.ver...@croit.io Chat: https://t.me/MartinVerges croit GmbH, Freseniusstr. 31h, 81247 Munich CEO: Martin Verges - VAT-ID: DE310638492 Com. register: Amtsgericht Munich HRB 231263 Web: https://croit.io YouTube: https://goo.gl/PGE1Bx Am Do., 9. Jan. 2020 um 14:23 Uhr schrieb Martin Verges < martin.ver...@croit.io>: > Hello Thomas, > > 1. we provide 14.2.5, the latest stable release available (we have >> upcoming 14.2.6 already on track) >> > > Good to know, does not seem to be a knowledge that some proxmox users have > nor was it the case in the past. > > >> If you have custom patches which improve the experience I'd suggest >> up-streaming them to Ceph or, if they affect our management tooling for >> ceph, telling us here or at bugzilla.proxmox.com and/or naturally >> up-streaming them to PVE. >> > > As a founding member of the Ceph foundation, we always provide all patches > to the Ceph upstream and as always they will be included in future releases > of Ceph or backported to older versions. > > The Ceph integration from a client perspective should work as with every >> other >> "external" ceph server setup. IMO, it makes no sense to mix our >> management >> interface for Ceph with externally untested builds. We sync releases of >> Ceph >> on our side with releases of the management stack, that would be >> circumvented >> completely, as would be the testing of the Ceph setup. >> >> If people want to use croit that's naturally fine for us, they can use the >> croit managed ceph cluster within PVE instances as RBD or CephFS client >> just >> fine, as it is and was always the case. But, mixing croit packages with >> PVE >> management makes not much sense to me, I'm afraid. >> > > I agree that user should stick to the versions a vendor provides, in your > case the proxmox Ceph versions. But as I already wrote, we get a lot of > proxmox users on our table that use proxmox and Ceph and some seem to have > an issue. > > As my fix does not affect any proxmox functionality in a negative way, no > will it break anything. Why would you hesitate to allow users to choose the > Ceph versions of their liking? It just enables proxmox to don't break on > such versions. > > -- > Martin Verges > Managing director > > Hint: Secure one of the last slots in the upcoming 4-day Ceph Intensive > Training at https://croit.io/training/4-days-ceph-in-depth-training. > > Mobile: +49 174 9335695 > E-Mail: martin.ver...@croit.io > Chat: https://t.me/MartinVerges > > croit GmbH, Freseniusstr. 31h, 81247 Munich > CEO: Martin Verges - VAT-ID: DE310638492 > Com. register: Amtsgericht Munich HRB 231263 > > Web: https://croit.io > YouTube: https://goo.gl/PGE1Bx > > > Am Mi., 8. Jan. 2020 um 18:06 Uhr schrieb Thomas Lamprecht < > t.lampre...@proxmox.com>: > >> On 1/8/20 5:27 PM, Martin Verges wrote: >> > Thanks, I added that for the future. >> >> Thanks. >> >> > I'm more used to the much more user friendly github / gitlab. >> >> That's rather subjective, I for one, find mailing list much more >> enjoyable and >> easier for review and development work - to each their own. >> >> > However we provide our own croit Ceph debian repository that a lot of >> > people use to get newer, better Ceph versions into your software. >> >> We always follow upstream closely and are among the first to test and >> report >> issues or send fixes, especially if they affect the Debian based builds of >> Ceph and/or our integration with Ceph. >> I'm not sure how you can provided better and newer Ceph builds for >> Proxmox VE >> as: >> 1. we provide 14.2.5, the latest stable release available (we have >> upcoming >>14.2.6 already on tra
Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules
>>Hmm, not here, diff between the two says there's no differences, also checking >>out the file shows that the ifupdown2 2.0.1-1 tag has this commented out: oh, sorry. maybe I was drunk ^_^. - Mail original - De: "Thomas Lamprecht" À: "Alexandre Derumier" Cc: "pve-devel" Envoyé: Jeudi 9 Janvier 2020 14:10:29 Objet: Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules On 1/9/20 2:05 PM, Alexandre DERUMIER wrote: >>> this is the exact same one as ifupdown2 ships in it's debian/ folder, so as >>> we >>> just sync our debian folder into their (i.e., no full overwrite) we could >>> omit this. >>> Or do I miss something? > > I have commented > > #export DH_VERBOSE=1 > > I don't know why, but when it's enabled, the patches series don't seem to be > applied when dpkg-buildpackage is running > (don't have found any infos about this) Hmm, not here, diff between the two says there's no differences, also checking out the file shows that the ifupdown2 2.0.1-1 tag has this commented out: $ git checkout 2.0.1-1 HEAD is now at e65fae4 debian: changelog: new 2.0.1-1 entry $ head debian/rules #!/usr/bin/make -f #export DH_VERBOSE=1 export PYBUILD_NAME=ifupdown2 export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ --install-scripts=/usr/share/ %: dh $@ --with python2 --with systemd --buildsystem=pybuild override_dh_installman: As this builds here I'll just omit the 2/3 patch :) > > - Mail original - > De: "Thomas Lamprecht" > À: "pve-devel" , "Alexandre Derumier" > > Envoyé: Jeudi 9 Janvier 2020 13:09:30 > Objet: Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules > > On 1/9/20 12:23 PM, Alexandre Derumier wrote: >> comment export DH_VERBOSE=1 to have patches applied >> >> Signed-off-by: Alexandre Derumier >> --- >> debian/rules | 27 +++ >> 1 file changed, 27 insertions(+) >> create mode 100755 debian/rules >> >> diff --git a/debian/rules b/debian/rules >> new file mode 100755 >> index 000..6274b3a >> --- /dev/null >> +++ b/debian/rules >> @@ -0,0 +1,27 @@ >> +#!/usr/bin/make -f >> + >> +#export DH_VERBOSE=1 >> +export PYBUILD_NAME=ifupdown2 >> +export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ >> --install-scripts=/usr/share/ >> + >> +%: >> + dh $@ --with python2 --with systemd --buildsystem=pybuild >> + >> +override_dh_installman: >> + ./ifupdown2/man/genmanpages.sh ./ifupdown2/man ./man >> + dh_installman >> + >> +override_dh_install: >> + dh_install >> + mkdir -p debian/ifupdown2/lib/systemd/system/ >> + install --mode=644 debian/ifup@.service >> debian/ifupdown2/lib/systemd/system/ >> + >> + >> +override_dh_systemd_start: >> + dh_systemd_start --name=networking --no-start >> + >> +override_dh_systemd_enable: >> + dh_systemd_enable --name=networking >> + >> +override_dh_compress: >> + dh_compress -X.py >> > > this is the exact same one as ifupdown2 ships in it's debian/ folder, so as > we > just sync our debian folder into their (i.e., no full overwrite) we could > omit this. > Or do I miss something? > > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pmg-api 1/2] api2: network: add bond-primary option
Signed-off-by: Alexandre Derumier
---
src/PMG/API2/Network.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/PMG/API2/Network.pm b/src/PMG/API2/Network.pm
index b6a58da..1c3e8c1 100644
--- a/src/PMG/API2/Network.pm
+++ b/src/PMG/API2/Network.pm
@@ -101,6 +101,11 @@ my $confdesc = {
optional => 1,
type => 'string', enum => $bond_mode_enum,
},
+'bond-primary' => {
+ description => "Specify the primary interface for active-backup bond.",
+ optional => 1,
+ type => 'string', format => 'pve-iface',
+},
bond_xmit_hash_policy => {
description => "Selects the transmit hash policy to use for slave
selection in balance-xor and 802.3ad modes.",
optional => 1,
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pmg-api 0/2] local network config improvements
Same than pve-manager Alexandre Derumier (2): api2: network: add bond-primary option api2 : network : add mtu src/PMG/API2/Network.pm | 12 1 file changed, 12 insertions(+) -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pmg-api 2/2] api2 : network : add mtu
min 1280 to handle ipv6 && ipv4
max 65520 (infinibad support it)
Signed-off-by: Alexandre Derumier
---
src/PMG/API2/Network.pm | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/PMG/API2/Network.pm b/src/PMG/API2/Network.pm
index 1c3e8c1..ed6651d 100644
--- a/src/PMG/API2/Network.pm
+++ b/src/PMG/API2/Network.pm
@@ -134,6 +134,13 @@ my $confdesc = {
type => 'string', format => 'CIDRv4',
optional => 1,
},
+mtu => {
+ description => 'MTU.',
+ optional => 1,
+ type => 'integer',
+ minimum => 1280,
+ maximum => 65520,
+},
gateway6 => {
description => 'Default ipv6 gateway address.',
type => 'string', format => 'ipv6',
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ceph 1/2] fix Ceph version string handling
Hello Thomas, 1. we provide 14.2.5, the latest stable release available (we have upcoming > 14.2.6 already on track) > Good to know, does not seem to be a knowledge that some proxmox users have nor was it the case in the past. > If you have custom patches which improve the experience I'd suggest > up-streaming them to Ceph or, if they affect our management tooling for > ceph, telling us here or at bugzilla.proxmox.com and/or naturally > up-streaming them to PVE. > As a founding member of the Ceph foundation, we always provide all patches to the Ceph upstream and as always they will be included in future releases of Ceph or backported to older versions. The Ceph integration from a client perspective should work as with every > other > "external" ceph server setup. IMO, it makes no sense to mix our management > interface for Ceph with externally untested builds. We sync releases of > Ceph > on our side with releases of the management stack, that would be > circumvented > completely, as would be the testing of the Ceph setup. > > If people want to use croit that's naturally fine for us, they can use the > croit managed ceph cluster within PVE instances as RBD or CephFS client > just > fine, as it is and was always the case. But, mixing croit packages with PVE > management makes not much sense to me, I'm afraid. > I agree that user should stick to the versions a vendor provides, in your case the proxmox Ceph versions. But as I already wrote, we get a lot of proxmox users on our table that use proxmox and Ceph and some seem to have an issue. As my fix does not affect any proxmox functionality in a negative way, no will it break anything. Why would you hesitate to allow users to choose the Ceph versions of their liking? It just enables proxmox to don't break on such versions. -- Martin Verges Managing director Hint: Secure one of the last slots in the upcoming 4-day Ceph Intensive Training at https://croit.io/training/4-days-ceph-in-depth-training. Mobile: +49 174 9335695 E-Mail: martin.ver...@croit.io Chat: https://t.me/MartinVerges croit GmbH, Freseniusstr. 31h, 81247 Munich CEO: Martin Verges - VAT-ID: DE310638492 Com. register: Amtsgericht Munich HRB 231263 Web: https://croit.io YouTube: https://goo.gl/PGE1Bx Am Mi., 8. Jan. 2020 um 18:06 Uhr schrieb Thomas Lamprecht < t.lampre...@proxmox.com>: > On 1/8/20 5:27 PM, Martin Verges wrote: > > Thanks, I added that for the future. > > Thanks. > > > I'm more used to the much more user friendly github / gitlab. > > That's rather subjective, I for one, find mailing list much more enjoyable > and > easier for review and development work - to each their own. > > > However we provide our own croit Ceph debian repository that a lot of > > people use to get newer, better Ceph versions into your software. > > We always follow upstream closely and are among the first to test and > report > issues or send fixes, especially if they affect the Debian based builds of > Ceph and/or our integration with Ceph. > I'm not sure how you can provided better and newer Ceph builds for Proxmox > VE > as: > 1. we provide 14.2.5, the latest stable release available (we have upcoming >14.2.6 already on track) > 2. we explicitly build and test Ceph on Proxmox VE, i.e., to make it as > first >class enterprise ready as possible, especially if paired with PVE. > > If you have custom patches which improve the experience I'd suggest > up-streaming them to Ceph or, if they affect our management tooling for > ceph, > telling us here or at bugzilla.proxmox.com and/or naturally up-streaming > them > to PVE. > > > One of your proxmox users came to us, complaining that our package named > > "ceph version 14.2.5-1-g23e76c7aa6 > > (23e76c7aa6e15817ffb6741aafbc95ca99f24cbb) nautilus (stable)" breaks the > > proxmox software. > > The Ceph integration from a client perspective should work as with every > other > "external" ceph server setup. IMO, it makes no sense to mix our management > interface for Ceph with externally untested builds. We sync releases of > Ceph > on our side with releases of the management stack, that would be > circumvented > completely, as would be the testing of the Ceph setup. > > If people want to use croit that's naturally fine for us, they can use the > croit managed ceph cluster within PVE instances as RBD or CephFS client > just > fine, as it is and was always the case. But, mixing croit packages with PVE > management makes not much sense to me, I'm afraid. > > Thanks, > Thomas > > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 4/4] INotify: network : add ovs_mtu option
This is also rewriting any "mtu" option on a ovs interface
to "ovs_mtu"
Signed-off-by: Alexandre Derumier
---
src/PVE/INotify.pm | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index e3e43c1..d1731fc 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -872,6 +872,7 @@ sub __read_etc_network_interfaces {
my $options = $config->{options} = [];
my $options_alternatives = {
+ 'ovs_mtu' => 'mtu',
'bond-slaves' => 'slaves',
'bond_slaves' => 'slaves',
'bond-xmit-hash-policy' => 'bond_xmit_hash_policy',
@@ -1215,6 +1216,9 @@ sub __interface_to_string {
$done->{bridge_vlan_aware} = 1;
$done->{bridge_vids} = 1;
+ $raw .= "\tmtu $d->{mtu}\n" if $d->{mtu};
+ $done->{mtu} = 1;
+
} elsif ($d->{type} eq 'bond') {
$d->{slaves} =~ s/[;,\s]+/ /g;
@@ -1241,6 +1245,9 @@ sub __interface_to_string {
}
$done->{'bond-primary'} = 1;
+ $raw .= "\tmtu $d->{mtu}\n" if $d->{mtu};
+ $done->{mtu} = 1;
+
} elsif ($d->{type} eq 'vlan') {
die "$iface: wrong vlan-protocol $d->{'vlan-protocol'}\n"
if $d->{'vlan-protocol'} && $d->{'vlan-protocol'} ne '802.1ad' &&
$d->{'vlan-protocol'} ne '802.1q';
@@ -1258,14 +1265,21 @@ sub __interface_to_string {
}
$done->{'vxlan-remoteip'} = 1;
}
+
+ $raw .= "\tmtu $d->{mtu}\n" if $d->{mtu};
+ $done->{mtu} = 1;
+
} elsif ($d->{type} eq 'OVSBridge') {
$raw .= "\tovs_type $d->{type}\n";
$done->{ovs_type} = 1;
$raw .= "\tovs_ports $d->{ovs_ports}\n" if $d->{ovs_ports};
-
$done->{ovs_ports} = 1;
+
+ $raw .= "\tovs_mtu $d->{mtu}\n" if $d->{mtu};
+ $done->{mtu} = 1;
+
} elsif ($d->{type} eq 'OVSPort' || $d->{type} eq 'OVSIntPort' ||
$d->{type} eq 'OVSBond') {
@@ -1307,6 +1321,9 @@ sub __interface_to_string {
$raw .= "\tovs_bridge $bridge\n";
$done->{ovs_bridge} = 1;
}
+
+ $raw .= "\tovs_mtu $d->{mtu}\n" if $d->{mtu};
+ $done->{mtu} = 1;
}
if ($first_block) {
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 0/4] network config improvements
This is patches series with some patches I have already send this week. This add some missing options, fix some others. changelog2: -fix Inotify: forbid ip address on bridged interface test :: for ipv6 seem enough) (Note that gui forbid 0.0.0.0 && ::, but this is just in case of manual edit of config file) - remove patch5 (already applied) Alexandre Derumier (4): Inotify: forbid ip address on bridged interface. INotify: allow vlan tagged bridge interface on non-vlanaware bridge INotify: add bond-primary option INotify: network : add ovs_mtu option src/PVE/INotify.pm | 39 ++- 1 file changed, 34 insertions(+), 5 deletions(-) -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 2/4] INotify: allow vlan tagged bridge interface on non-vlanaware bridge
Seem that it's working too with non-vlanaware bridge
Signed-off-by: Alexandre Derumier
---
src/PVE/INotify.pm | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index b38d887..1a528fa 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1474,9 +1474,7 @@ sub __write_etc_network_interfaces {
die "vlan '$iface' - unable to find parent '$p'\n"
if !$n;
- if ($n->{type} eq 'bridge' && !$n->{bridge_vlan_aware}) {
- die "vlan '$iface' - bridge vlan aware is not enabled on parent
'$p'\n";
- } elsif ($n->{type} ne 'eth' && $n->{type} ne 'bridge' &&
$n->{type} ne 'bond' && $n->{type} ne 'vlan') {
+ if ($n->{type} ne 'eth' && $n->{type} ne 'bridge' && $n->{type} ne
'bond' && $n->{type} ne 'vlan') {
die "vlan '$iface' - wrong interface type on parent '$p' " .
"('$n->{type}' != 'eth|bond|bridge|vlan' )\n";
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 1/4] Inotify: forbid ip address on bridged interface.
Signed-off-by: Alexandre Derumier
---
src/PVE/INotify.pm | 4
1 file changed, 4 insertions(+)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 867da30..b38d887 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1512,6 +1512,10 @@ sub __write_etc_network_interfaces {
my $n = $ifaces->{$p};
die "bridge '$iface' - unable to find bridge port '$p'\n"
if !$n;
+ die "iface $p - ip address can't be set on interface if bridged
in $iface\n"
+ if ($n->{method} eq 'static' && $n->{address} ne '0.0.0.0')
||
+ ($n->{method6} eq 'static' && $n->{address} ne "\:\:");
+
&$check_mtu($ifaces, $iface, $p);
$bridgeports->{$p} = $iface;
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 3/4] INotify: add bond-primary option
Signed-off-by: Alexandre Derumier
---
src/PVE/INotify.pm | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 1a528fa..e3e43c1 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -956,6 +956,7 @@ sub __read_etc_network_interfaces {
'bridge-multicast-flood' => 1,
'bond_miimon' => 1,
'bond_xmit_hash_policy' => 1,
+ 'bond-primary' => 1,
'uplink-id' => 1,
'vlan-protocol' => 1,
'vxlan-id' => 1,
@@ -1234,6 +1235,12 @@ sub __interface_to_string {
$raw .= "\tbond-xmit-hash-policy $d->{'bond_xmit_hash_policy'}\n";
}
$done->{'bond_xmit_hash_policy'} = 1;
+
+ if ($d->{'bond_mode'} && $d->{'bond_mode'} eq 'active-backup' &&
$d->{'bond-primary'}) {
+ $raw .= "\tbond-primary $d->{'bond-primary'}\n";
+ }
+ $done->{'bond-primary'} = 1;
+
} elsif ($d->{type} eq 'vlan') {
die "$iface: wrong vlan-protocol $d->{'vlan-protocol'}\n"
if $d->{'vlan-protocol'} && $d->{'vlan-protocol'} ne '802.1ad' &&
$d->{'vlan-protocol'} ne '802.1q';
@@ -1427,15 +1434,18 @@ sub __write_etc_network_interfaces {
foreach my $iface (keys %$ifaces) {
my $d = $ifaces->{$iface};
if ($d->{type} eq 'bond' && $d->{slaves}) {
+ my $bond_primary_is_slave = undef;
foreach my $p (split (/\s+/, $d->{slaves})) {
my $n = $ifaces->{$p};
-
+
die "bond '$iface' - unable to find slave '$p'\n"
if !$n;
die "bond '$iface' - wrong interface type on slave '$p' " .
"('$n->{type}' != 'eth')\n" if $n->{type} ne 'eth';
&$check_mtu($ifaces, $iface, $p);
+ $bond_primary_is_slave = 1 if $d->{'bond-primary'} &&
$d->{'bond-primary'} eq $p;
}
+ die "bond '$iface' - bond-primary interface is not a slave" if
$d->{'bond-primary'} && !$bond_primary_is_slave;
}
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules
On 1/9/20 2:05 PM, Alexandre DERUMIER wrote: >>> this is the exact same one as ifupdown2 ships in it's debian/ folder, so as >>> we >>> just sync our debian folder into their (i.e., no full overwrite) we could >>> omit this. >>> Or do I miss something? > > I have commented > > #export DH_VERBOSE=1 > > I don't know why, but when it's enabled, the patches series don't seem to be > applied when dpkg-buildpackage is running > (don't have found any infos about this) Hmm, not here, diff between the two says there's no differences, also checking out the file shows that the ifupdown2 2.0.1-1 tag has this commented out: $ git checkout 2.0.1-1 HEAD is now at e65fae4 debian: changelog: new 2.0.1-1 entry $ head debian/rules #!/usr/bin/make -f #export DH_VERBOSE=1 export PYBUILD_NAME=ifupdown2 export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ --install-scripts=/usr/share/ %: dh $@ --with python2 --with systemd --buildsystem=pybuild override_dh_installman: As this builds here I'll just omit the 2/3 patch :) > > - Mail original - > De: "Thomas Lamprecht" > À: "pve-devel" , "Alexandre Derumier" > > Envoyé: Jeudi 9 Janvier 2020 13:09:30 > Objet: Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules > > On 1/9/20 12:23 PM, Alexandre Derumier wrote: >> comment export DH_VERBOSE=1 to have patches applied >> >> Signed-off-by: Alexandre Derumier >> --- >> debian/rules | 27 +++ >> 1 file changed, 27 insertions(+) >> create mode 100755 debian/rules >> >> diff --git a/debian/rules b/debian/rules >> new file mode 100755 >> index 000..6274b3a >> --- /dev/null >> +++ b/debian/rules >> @@ -0,0 +1,27 @@ >> +#!/usr/bin/make -f >> + >> +#export DH_VERBOSE=1 >> +export PYBUILD_NAME=ifupdown2 >> +export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ >> --install-scripts=/usr/share/ >> + >> +%: >> + dh $@ --with python2 --with systemd --buildsystem=pybuild >> + >> +override_dh_installman: >> + ./ifupdown2/man/genmanpages.sh ./ifupdown2/man ./man >> + dh_installman >> + >> +override_dh_install: >> + dh_install >> + mkdir -p debian/ifupdown2/lib/systemd/system/ >> + install --mode=644 debian/ifup@.service >> debian/ifupdown2/lib/systemd/system/ >> + >> + >> +override_dh_systemd_start: >> + dh_systemd_start --name=networking --no-start >> + >> +override_dh_systemd_enable: >> + dh_systemd_enable --name=networking >> + >> +override_dh_compress: >> + dh_compress -X.py >> > > this is the exact same one as ifupdown2 ships in it's debian/ folder, so as > we > just sync our debian folder into their (i.e., no full overwrite) we could > omit this. > Or do I miss something? > > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules
>>this is the exact same one as ifupdown2 ships in it's debian/ folder, so as >>we >>just sync our debian folder into their (i.e., no full overwrite) we could >>omit this. >>Or do I miss something? I have commented #export DH_VERBOSE=1 I don't know why, but when it's enabled, the patches series don't seem to be applied when dpkg-buildpackage is running (don't have found any infos about this) - Mail original - De: "Thomas Lamprecht" À: "pve-devel" , "Alexandre Derumier" Envoyé: Jeudi 9 Janvier 2020 13:09:30 Objet: Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules On 1/9/20 12:23 PM, Alexandre Derumier wrote: > comment export DH_VERBOSE=1 to have patches applied > > Signed-off-by: Alexandre Derumier > --- > debian/rules | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100755 debian/rules > > diff --git a/debian/rules b/debian/rules > new file mode 100755 > index 000..6274b3a > --- /dev/null > +++ b/debian/rules > @@ -0,0 +1,27 @@ > +#!/usr/bin/make -f > + > +#export DH_VERBOSE=1 > +export PYBUILD_NAME=ifupdown2 > +export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ > --install-scripts=/usr/share/ > + > +%: > + dh $@ --with python2 --with systemd --buildsystem=pybuild > + > +override_dh_installman: > + ./ifupdown2/man/genmanpages.sh ./ifupdown2/man ./man > + dh_installman > + > +override_dh_install: > + dh_install > + mkdir -p debian/ifupdown2/lib/systemd/system/ > + install --mode=644 debian/ifup@.service > debian/ifupdown2/lib/systemd/system/ > + > + > +override_dh_systemd_start: > + dh_systemd_start --name=networking --no-start > + > +override_dh_systemd_enable: > + dh_systemd_enable --name=networking > + > +override_dh_compress: > + dh_compress -X.py > this is the exact same one as ifupdown2 ships in it's debian/ folder, so as we just sync our debian folder into their (i.e., no full overwrite) we could omit this. Or do I miss something? ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules
On 1/9/20 12:23 PM, Alexandre Derumier wrote: > comment export DH_VERBOSE=1 to have patches applied > > Signed-off-by: Alexandre Derumier > --- > debian/rules | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100755 debian/rules > > diff --git a/debian/rules b/debian/rules > new file mode 100755 > index 000..6274b3a > --- /dev/null > +++ b/debian/rules > @@ -0,0 +1,27 @@ > +#!/usr/bin/make -f > + > +#export DH_VERBOSE=1 > +export PYBUILD_NAME=ifupdown2 > +export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ > --install-scripts=/usr/share/ > + > +%: > + dh $@ --with python2 --with systemd --buildsystem=pybuild > + > +override_dh_installman: > + ./ifupdown2/man/genmanpages.sh ./ifupdown2/man ./man > + dh_installman > + > +override_dh_install: > + dh_install > + mkdir -p debian/ifupdown2/lib/systemd/system/ > + install --mode=644 debian/ifup@.service > debian/ifupdown2/lib/systemd/system/ > + > + > +override_dh_systemd_start: > + dh_systemd_start --name=networking --no-start > + > +override_dh_systemd_enable: > + dh_systemd_enable --name=networking > + > +override_dh_compress: > + dh_compress -X.py > this is the exact same one as ifupdown2 ships in it's debian/ folder, so as we just sync our debian folder into their (i.e., no full overwrite) we could omit this. Or do I miss something? ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH firewall] api node: always pass cluster conf to node FW parser
On 1/9/20 1:03 PM, Thomas Lamprecht wrote:
> As else the parsing may lead to "false positive" errors, as cluster
> wide aliases and other definitions are seemingly missing.
>
> Reproducer:
> * add *cluster* alias
> * add+enable *host* rule using that alias
> * enable FW on DC and node level
> * go to Node -> FW -> Options
> * check journal/syslog for error like:
>> pveproxy[1339680]: /etc/pve/nodes/dev6/host.fw (line 3) - errors in rule
>> parameters: IN ACCEPT -source test123 -p tcp -sport 22 -log nolog
>> pveproxy[1339680]: source: no such alias 'test123'
>
> Signed-off-by: Thomas Lamprecht
> ---
> src/PVE/API2/Firewall/Host.pm | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/PVE/API2/Firewall/Host.pm b/src/PVE/API2/Firewall/Host.pm
> index d02619a..2303494 100644
> --- a/src/PVE/API2/Firewall/Host.pm
> +++ b/src/PVE/API2/Firewall/Host.pm
> @@ -86,7 +86,8 @@ __PACKAGE__->register_method({
> code => sub {
> my ($param) = @_;
>
> - my $hostfw_conf = PVE::Firewall::load_hostfw_conf();
> + my $cluster_conf = PVE::Firewall::load_clusterfw_conf();
> + my $hostfw_conf = PVE::Firewall::load_hostfw_conf($cluster_conf);
>
> return PVE::Firewall::copy_opject_with_digest($hostfw_conf->{options});
> }});
> @@ -117,7 +118,8 @@ __PACKAGE__->register_method({
> code => sub {
> my ($param) = @_;
>
> - my $hostfw_conf = PVE::Firewall::load_hostfw_conf();
> + my $cluster_conf = PVE::Firewall::load_clusterfw_conf();
> + my $hostfw_conf = PVE::Firewall::load_hostfw_conf($cluster_conf);
>
> my (undef, $digest) =
> PVE::Firewall::copy_opject_with_digest($hostfw_conf->{options});
> PVE::Tools::assert_if_modified($digest, $param->{digest});
>
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH firewall] api node: always pass cluster conf to node FW parser
As else the parsing may lead to "false positive" errors, as cluster
wide aliases and other definitions are seemingly missing.
Reproducer:
* add *cluster* alias
* add+enable *host* rule using that alias
* enable FW on DC and node level
* go to Node -> FW -> Options
* check journal/syslog for error like:
> pveproxy[1339680]: /etc/pve/nodes/dev6/host.fw (line 3) - errors in rule
> parameters: IN ACCEPT -source test123 -p tcp -sport 22 -log nolog
> pveproxy[1339680]: source: no such alias 'test123'
Signed-off-by: Thomas Lamprecht
---
src/PVE/API2/Firewall/Host.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/PVE/API2/Firewall/Host.pm b/src/PVE/API2/Firewall/Host.pm
index d02619a..2303494 100644
--- a/src/PVE/API2/Firewall/Host.pm
+++ b/src/PVE/API2/Firewall/Host.pm
@@ -86,7 +86,8 @@ __PACKAGE__->register_method({
code => sub {
my ($param) = @_;
- my $hostfw_conf = PVE::Firewall::load_hostfw_conf();
+ my $cluster_conf = PVE::Firewall::load_clusterfw_conf();
+ my $hostfw_conf = PVE::Firewall::load_hostfw_conf($cluster_conf);
return PVE::Firewall::copy_opject_with_digest($hostfw_conf->{options});
}});
@@ -117,7 +118,8 @@ __PACKAGE__->register_method({
code => sub {
my ($param) = @_;
- my $hostfw_conf = PVE::Firewall::load_hostfw_conf();
+ my $cluster_conf = PVE::Firewall::load_clusterfw_conf();
+ my $hostfw_conf = PVE::Firewall::load_hostfw_conf($cluster_conf);
my (undef, $digest) =
PVE::Firewall::copy_opject_with_digest($hostfw_conf->{options});
PVE::Tools::assert_if_modified($digest, $param->{digest});
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 ifupdown2 3/3] bump 2.0.1-1+pve1
Signed-off-by: Alexandre Derumier --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index bb44795..ff33f67 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +ifupdown2 (2.0.1-1+pve1) pve; urgency=medium + + * Bump to 2.0.1 + + -- Proxmox Support Team Tue, 6 Jan 2020 12:24:12 +0100 + ifupdown2 (1.2.8-1+pve4) pve; urgency=medium * add arp-accept option required for bgp-evpn -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 ifupdown2 1/3] update patches
remove add-uplink-id-option.patch (not needed),
remove arp-accept option patch (available upstream)
remove debian-fixup-networking.service.patch (new @ifup service upstream)
rebase others patches
Signed-off-by: Alexandre Derumier
---
...-veth-fwpr-interfaces-from-bridge-on.patch | 44 +
...add-dummy-mtu-bridgevlanport-modules.patch | 11 ++--
...subinterface-in-a-vlan-aware-bridge.patch} | 11 ++--
...0003-debian-fixup-networking.service.patch | 64 ---
...ridge-is-tap-veth-are-still-plugged.patch} | 11 ++--
...vxlan-interfaces-when-ifreload_down.patch} | 11 ++--
.../pve/0006-add-uplink-id-option.patch | 27
...-tuning.patch => 0006-config-tuning.patch} | 8 +--
.../pve/0009-add-arp-accept-option.patch | 55
debian/patches/series | 11 ++--
10 files changed, 66 insertions(+), 187 deletions(-)
rename
debian/patches/pve/{0004-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch
=> 0003-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch} (86%)
delete mode 100644
debian/patches/pve/0003-debian-fixup-networking.service.patch
rename
debian/patches/pve/{0005-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch
=> 0004-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch} (86%)
rename
debian/patches/pve/{0007-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch
=> 0005-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch} (85%)
delete mode 100644 debian/patches/pve/0006-add-uplink-id-option.patch
rename debian/patches/pve/{0008-config-tuning.patch =>
0006-config-tuning.patch} (82%)
delete mode 100644 debian/patches/pve/0009-add-arp-accept-option.patch
diff --git
a/debian/patches/pve/0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch
b/debian/patches/pve/0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch
index 8e0e7bf..869f0f3 100644
---
a/debian/patches/pve/0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch
+++
b/debian/patches/pve/0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch
@@ -1,30 +1,43 @@
-From Mon Sep 17 00:00:00 2001
+From 874ba884a7ff8f0059e069aac2855c2ffd5cacd2 Mon Sep 17 00:00:00 2001
From: Alexandre Derumier
Date: Wed, 16 May 2018 02:11:45 +0200
-Subject: [PATCH] don't remove (tap|veth|fwpr) interfaces from bridge on ifup
- bridge
+Subject: [PATCH 1/7] don't remove (tap|veth|fwpr) interfaces from bridge on
+ ifup bridge
as proxmox don't defined them in /etc/network/interfaces
Signed-off-by: Thomas Lamprecht
Signed-off-by: Alexandre Derumier
---
+ debian/rules | 2 +-
ifupdown2/addons/bridge.py | 4
- 1 file changed, 4 insertions(+)
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+diff --git a/debian/rules b/debian/rules
+index 6274b3a..dfd460f 100755
+--- a/debian/rules
b/debian/rules
+@@ -1,6 +1,6 @@
+ #!/usr/bin/make -f
+
+-#export DH_VERBOSE=1
++export DH_VERBOSE=1
+ export PYBUILD_NAME=ifupdown2
+ export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/
--install-scripts=/usr/share/
+
diff --git a/ifupdown2/addons/bridge.py b/ifupdown2/addons/bridge.py
-index 3e5fd78..bd597d7 100644
+index 00b1eaa..35944ac 100644
--- a/ifupdown2/addons/bridge.py
+++ b/ifupdown2/addons/bridge.py
-@@ -79,6 +79,7 @@ class bridge(moduleBase):
-'bridge-ports-condone-regex' :
- {'help' : 'bridge ports to ignore/condone when
reloading config / removing interfaces',
- 'required' : False,
-+ 'default' : '^(tap|veth|fwpr)',
- 'example' : [ 'bridge-ports-condone-regex
^[a-zA-Z0-9]+_v[0-9]{1,4}$']},
-'bridge-stp' :
- {'help': 'bridge-stp yes/no',
-@@ -912,6 +913,9 @@ class bridge(moduleBase):
+@@ -440,6 +440,7 @@ class bridge(Addon, moduleBase):
+ "bridge-ports-condone-regex": {
+ "help": "bridge ports to ignore/condone when reloading
config / removing interfaces",
+ "required": False,
++"default": "^(tap|veth|fwpr)",
+ "example": ["bridge-ports-condone-regex
^[a-zA-Z0-9]+_v[0-9]{1,4}$"]
+ },
+ }
+@@ -1006,6 +1007,9 @@ class bridge(Addon, moduleBase):
# up a compiled regex to be used in a match later. This way we try to
avoid
# a race condition where an (possibly VM) interface is created after
this
# function has been called but before the bridgeports are validated.
@@ -34,3 +47,6 @@ index 3e5fd78..bd597d7 100644
if bridge_port_condone_regex:
if get_string:
return bridge_port_condone_regex
+--
+2.20.1
+
diff --git a/debian/patches/pve/0002-add-dummy-mtu-bridgevlanport-modules.patch
b/debian/patches/pve/0002-add-dummy-mtu-bridgevlanport-modules.patch
index 2ba6810..c9e22d5 100644
--- a/debian/patches/pve/0
[pve-devel] [PATCH V2 ifupdown2 2/3] add debian/rules
comment export DH_VERBOSE=1 to have patches applied Signed-off-by: Alexandre Derumier --- debian/rules | 27 +++ 1 file changed, 27 insertions(+) create mode 100755 debian/rules diff --git a/debian/rules b/debian/rules new file mode 100755 index 000..6274b3a --- /dev/null +++ b/debian/rules @@ -0,0 +1,27 @@ +#!/usr/bin/make -f + +#export DH_VERBOSE=1 +export PYBUILD_NAME=ifupdown2 +export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/ --install-scripts=/usr/share/ + +%: + dh $@ --with python2 --with systemd --buildsystem=pybuild + +override_dh_installman: + ./ifupdown2/man/genmanpages.sh ./ifupdown2/man ./man + dh_installman + +override_dh_install: + dh_install + mkdir -p debian/ifupdown2/lib/systemd/system/ + install --mode=644 debian/ifup@.service debian/ifupdown2/lib/systemd/system/ + + +override_dh_systemd_start: + dh_systemd_start --name=networking --no-start + +override_dh_systemd_enable: + dh_systemd_enable --name=networking + +override_dh_compress: + dh_compress -X.py -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 ifupdown2 0/3] bump to 2.0.1
Need to update the submodule repo.
I have done tests with vlan,qinq,vxlan,vrf,bonding,...
I don't have find any regression.
changelog v2:
add missing patches files
Alexandre Derumier (3):
update patches
add debian/rules
bump 2.0.1-1+pve1
debian/changelog | 6 ++
...-veth-fwpr-interfaces-from-bridge-on.patch | 44 +
...add-dummy-mtu-bridgevlanport-modules.patch | 11 ++--
...subinterface-in-a-vlan-aware-bridge.patch} | 11 ++--
...0003-debian-fixup-networking.service.patch | 64 ---
...ridge-is-tap-veth-are-still-plugged.patch} | 11 ++--
...vxlan-interfaces-when-ifreload_down.patch} | 11 ++--
.../pve/0006-add-uplink-id-option.patch | 27
...-tuning.patch => 0006-config-tuning.patch} | 8 +--
.../pve/0009-add-arp-accept-option.patch | 55
debian/patches/series | 11 ++--
debian/rules | 27
12 files changed, 99 insertions(+), 187 deletions(-)
rename
debian/patches/pve/{0004-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch
=> 0003-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch} (86%)
delete mode 100644
debian/patches/pve/0003-debian-fixup-networking.service.patch
rename
debian/patches/pve/{0005-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch
=> 0004-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch} (86%)
rename
debian/patches/pve/{0007-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch
=> 0005-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch} (85%)
delete mode 100644 debian/patches/pve/0006-add-uplink-id-option.patch
rename debian/patches/pve/{0008-config-tuning.patch =>
0006-config-tuning.patch} (82%)
delete mode 100644 debian/patches/pve/0009-add-arp-accept-option.patch
create mode 100755 debian/rules
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH ifupdown2 0/3] bump to 2.0.1
>>the diffstat shows you delete 0003 - 0006, not rebase them, so either the >>series file or the patches need to be fixed. >> >>Can you please retake a look at this? Sorry, I forgot "git add" on patches :/ - Mail original - De: "Thomas Lamprecht" À: "pve-devel" , "Alexandre Derumier" Envoyé: Mercredi 8 Janvier 2020 11:59:29 Objet: Re: [pve-devel] [PATCH ifupdown2 0/3] bump to 2.0.1 On 1/7/20 2:41 AM, Alexandre Derumier wrote: > Need to update the submodule repo. > > I have done tests with vlan,qinq,vxlan,vrf,bonding,... > I don't have find any regression. > series is a bit broken: * submodule update to targeted commit (tag 2.0.1-1) misses * debian/patches/series mentions: > pve/0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch > pve/0002-add-dummy-mtu-bridgevlanport-modules.patch > pve/0003-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch > pve/0004-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch > pve/0005-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch > pve/0006-config-tuning.patch but only the following two patch files are present after applying this series: 0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch 0002-add-dummy-mtu-bridgevlanport-modules.patch the diffstat shows you delete 0003 - 0006, not rebase them, so either the series file or the patches need to be fixed. Can you please retake a look at this? Thanks! > > Alexandre Derumier (3): > update patches > add debian/rules > bump 2.0.1-1+pve1 > > debian/changelog | 6 ++ > ...-veth-fwpr-interfaces-from-bridge-on.patch | 44 + > ...add-dummy-mtu-bridgevlanport-modules.patch | 11 ++-- > ...0003-debian-fixup-networking.service.patch | 64 --- > ...-subinterface-in-a-vlan-aware-bridge.patch | 46 - > ...bridge-is-tap-veth-are-still-plugged.patch | 32 -- > .../pve/0006-add-uplink-id-option.patch | 27 > ...-vxlan-interfaces-when-ifreload_down.patch | 31 - > debian/patches/pve/0008-config-tuning.patch | 29 - > .../pve/0009-add-arp-accept-option.patch | 55 > debian/patches/series | 11 ++-- > debian/rules | 27 > 12 files changed, 74 insertions(+), 309 deletions(-) > delete mode 100644 > debian/patches/pve/0003-debian-fixup-networking.service.patch > delete mode 100644 > debian/patches/pve/0004-allow-vlan-subinterface-in-a-vlan-aware-bridge.patch > delete mode 100644 > debian/patches/pve/0005-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch > > delete mode 100644 debian/patches/pve/0006-add-uplink-id-option.patch > delete mode 100644 > debian/patches/pve/0007-ifreload-down-up-vxlan-interfaces-when-ifreload_down.patch > > delete mode 100644 debian/patches/pve/0008-config-tuning.patch > delete mode 100644 debian/patches/pve/0009-add-arp-accept-option.patch > create mode 100755 debian/rules > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager 1/3] ifupdown1: bridgevlan: add bridge-vids list support
>> Before christmas i was testing the VLAN aware bridge functionality and >>I found the hard way that mlx4 based network cards don't support more >>than 128 VLAN's at the same time, or at least not with the default >>configuration. Hi, yes, I'm aware of this, I had mellanox connectx3 card, and I had this problem since kernel 4.15. >>I think that instead of adding ranges, the VID's should >>be added dynamically when a VM starts and it should check for fails too >>or else you could end up with a non working network card in the VM and >>no indication of the fail. The problem is that proxmox can't known exactly how much vlan can support a specific card. so if you had dynamically vlan, you could have the bug when more than 128 is dynamicly added, so it could break your proxmox host live when a vm will be started. so, adding the vlan in /etc/network/interfaces is more safe. (BTW, if ifupdown2 package, you can now reload network config online) - Mail original - De: "Jorge Boncompte" À: "pve-devel" Envoyé: Mercredi 8 Janvier 2020 19:15:25 Objet: Re: [pve-devel] [PATCH pve-manager 1/3] ifupdown1: bridgevlan: add bridge-vids list support El 8/1/20 a las 4:31, Alexandre Derumier escribió: > like ifupdown2, support multiple values > > iface vmbr0 > bridge-vids 2 4 5-10 70 Before christmas i was testing the VLAN aware bridge functionality and I found the hard way that mlx4 based network cards don't support more than 128 VLAN's at the same time, or at least not with the default configuration. I think that instead of adding ranges, the VID's should be added dynamically when a VM starts and it should check for fails too or else you could end up with a non working network card in the VM and no indication of the fail. Best regards. > > Signed-off-by: Alexandre Derumier > --- > network-hooks/bridgevlan | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/network-hooks/bridgevlan b/network-hooks/bridgevlan > index ea043575..3965bfda 100755 > --- a/network-hooks/bridgevlan > +++ b/network-hooks/bridgevlan > @@ -41,7 +41,10 @@ do > # we allow vlan to pass through attached interface > if [ -n "$IF_BRIDGE_VIDS" ] > then > - bridge vlan add dev $port vid $IF_BRIDGE_VIDS > + for VID in $IF_BRIDGE_VIDS > + do > + bridge vlan add dev $port vid $VID > + done > else > bridge vlan add dev $port vid 2-4094 > fi > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server] qemu_block_resize: align size to 512
Doing 'qm resize 111 scsi0 +0.2G' where scsi0 is a qcow2 disk
produced the following errors:
"VM 111 qmp command 'block_resize' failed - The new size must be a multiple of
512"
if the VM is running and
"qemu-img: The new size must be a multiple of 512"
if the VM isn't running
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 4
1 file changed, 4 insertions(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 2b68d81..2c92c3b 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -4668,6 +4668,10 @@ sub qemu_block_resize {
my $running = check_running($vmid);
+# aligning to 512 is required for qcow2 disks
+my $padding = (512 - $size % 512) % 512;
+$size = $size + $padding;
+
$size = 0 if !PVE::Storage::volume_resize($storecfg, $volid, $size,
$running);
return if !$running;
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] remove wrongly configured vmbr from bond example
On 1/9/20 9:36 AM, Dominik Csapak wrote: > the vmbr0 used eno1 as bridge_port, but it is already > in use by bond0, making the example wrong (as in, it does not work) and > confusing I mean the routes get setup correctly and all interfaces get created with the respective config, so it's a bit debatable.. But, it would be always a strange setup to have, so no objection to address this. > > since the example is about ip addresses on bonds, remove the vmbr0 > > Signed-off-by: Dominik Csapak > --- > pve-network.adoc | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/pve-network.adoc b/pve-network.adoc > index c61cd42..31cc168 100644 > --- a/pve-network.adoc > +++ b/pve-network.adoc > @@ -343,15 +343,6 @@ iface bond0 inet static >bond_mode 802.3ad >bond_xmit_hash_policy layer2+3 > > -auto vmbr0 > -iface vmbr0 inet static > -address 10.10.10.2 > -netmask 255.255.255.0 > -gateway 10.10.10.1 > -bridge_ports eno1 > -bridge_stp off > -bridge_fd 0 > - > > > > makes not much sense for a proxmox setup where guests are expected, I'd remove this whole example and just keep the one below which correctly has the bond0 as slave for vmbr0.. Or add a third network interface which is then used for the bridge. A hint that using a single port directly for as slave-port for more than one other interface does not work could be also good. ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server] Remove unused 'sharedvm' variable
AFAICT this one hasn't been in use since commit
'4530494bf9f3d45c4a405c53ef3688e641f6bd8e'
Signed-off-by: Fabian Ebner
---
PVE/QemuMigrate.pm | 5 -
1 file changed, 5 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 0353458..49848e8 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -282,8 +282,6 @@ sub sync_disks {
my $other_errors = [];
my $abort = 0;
- my $sharedvm = 1;
-
my $log_error = sub {
my ($msg, $volid) = @_;
@@ -310,7 +308,6 @@ sub sync_disks {
# check if storage is available on target node
PVE::Storage::storage_check_node($self->{storecfg}, $targetsid,
$self->{node});
- $sharedvm = 0; # there is a non-shared disk
PVE::Storage::foreach_volid($dl, sub {
my ($volid, $sid, $volname) = @_;
@@ -352,8 +349,6 @@ sub sync_disks {
return if $scfg->{shared};
- $sharedvm = 0;
-
$local_volumes->{$volid}->{ref} = $attr->{referenced_in_config} ?
'config' : 'snapshot';
if ($attr->{cdrom}) {
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager] fix #2334: gui/cloudinit: enable edit button only when editor is set
when a user does not have the right privileges for cloudinit (e.g.
VM.Config.Network), we do not set an editor, which results in a button
that does nothing when pressed
fix this by enabling the button only when there is an editor set
Signed-off-by: Dominik Csapak
---
www/manager6/qemu/CloudInit.js | 4
1 file changed, 4 insertions(+)
diff --git a/www/manager6/qemu/CloudInit.js b/www/manager6/qemu/CloudInit.js
index cb4742e5..cbb4af9d 100644
--- a/www/manager6/qemu/CloudInit.js
+++ b/www/manager6/qemu/CloudInit.js
@@ -65,6 +65,10 @@ Ext.define('PVE.qemu.CloudInit', {
{
xtype: 'proxmoxButton',
disabled: true,
+ enableFn: function(rec) {
+ let me = this.up('pveCiPanel');
+ return !!me.rows[rec.data.key].editor;
+ },
handler: function() {
var me = this.up('grid');
me.run_editor();
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs] remove wrongly configured vmbr from bond example
the vmbr0 used eno1 as bridge_port, but it is already in use by bond0, making the example wrong (as in, it does not work) and confusing since the example is about ip addresses on bonds, remove the vmbr0 Signed-off-by: Dominik Csapak --- pve-network.adoc | 9 - 1 file changed, 9 deletions(-) diff --git a/pve-network.adoc b/pve-network.adoc index c61cd42..31cc168 100644 --- a/pve-network.adoc +++ b/pve-network.adoc @@ -343,15 +343,6 @@ iface bond0 inet static bond_mode 802.3ad bond_xmit_hash_policy layer2+3 -auto vmbr0 -iface vmbr0 inet static -address 10.10.10.2 -netmask 255.255.255.0 -gateway 10.10.10.1 -bridge_ports eno1 -bridge_stp off -bridge_fd 0 - -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH proxmox-widget-toolkit 0/2] local network config improvements
On 1/9/20 5:57 AM, Alexandre DERUMIER wrote: looks mostly ok, (i'll write an extra mail with comments for 2/2) but if you add this, you also have to add the api functions for pmg[0] otherwise the next widget-toolkit update adds those fields that do not work there i guess that it would suffice (for now) to simply make the same changes from pve-managers Network.pm in pmg-api (longterm we should really refactor that...) sorry, I have forget about pmg. (I never has used it). no problem, but we have to be careful about that. we should probably mention somewhere in the dev-docs or in widget-toolkit that if they are modified, both pve and pmg have to be looked at I'll send patch today great :) - Mail original - De: "Dominik Csapak" À: "pve-devel" Envoyé: Mercredi 8 Janvier 2020 09:59:15 Objet: Re: [pve-devel] [PATCH proxmox-widget-toolkit 0/2] local network config improvements On 1/8/20 4:31 AM, Alexandre Derumier wrote: Following pve-common serie Alexandre Derumier (2): networkedit: bond: add bond-primary field networkedit: add mtu field node/NetworkEdit.js | 25 + 1 file changed, 25 insertions(+) looks mostly ok, (i'll write an extra mail with comments for 2/2) but if you add this, you also have to add the api functions for pmg[0] otherwise the next widget-toolkit update adds those fields that do not work there i guess that it would suffice (for now) to simply make the same changes from pve-managers Network.pm in pmg-api (longterm we should really refactor that...) 0: https://git.proxmox.com/?p=pmg-api.git;a=summary ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
