>>sounds OK, but I'd for now keep the "old" code here and just let SDN >>chain-call >>it, if required. >> >>We could for now do the "has SDN" in th e VM/CTs network hooks, else we'd >>have >>to make pve-network a default package dependency now, which may be a bit >>early >>yet?
yes, of course. >>Anyway, let's go your proposal way - but leave the existing create methods >>for now >>in common, I'd only move them fully over once we've pve-network default and we >>ensured that moving does not break the PMG or the like. I just send the patches. I have keep same sub parameters, so it'll should be easy to switch later when pve-network will be default. ----- Mail original ----- De: "Thomas Lamprecht" <t.lampre...@proxmox.com> À: "aderumier" <aderum...@odiso.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Lundi 9 Mars 2020 07:06:22 Objet: Re: applied: [pve-devel] [PATCH pve-common 1/1] Network: tap_create|plug : sdn : use bridge_vlan On 3/9/20 12:17 AM, Alexandre DERUMIER wrote: > I have this error with including it at top. OK, that would be really good to mention such things in the commit message, I just checked with `perl -wc Network.pm` But rethinking this now all with a bit more clear mind, it's quite sure wrong to use/require the SDN modules in common directly.. I'm going to revert yours and my followup patch for now. > > pvesh ls /cluster/sdn > Undefined subroutine &PVE::Cluster::cfs_register_file called at > /usr/share/perl5/PVE/Network/SDN/VnetPlugin.pm line 11. > Compilation failed in require at /usr/share/perl5/PVE/Network/SDN/Vnets.pm > line 9. > BEGIN failed--compilation aborted at > /usr/share/perl5/PVE/Network/SDN/Vnets.pm line 9. > Compilation failed in require at /usr/share/perl5/PVE/Network/SDN/Zones.pm > line 12. > BEGIN failed--compilation aborted at > /usr/share/perl5/PVE/Network/SDN/Zones.pm line 12. > Compilation failed in require at /usr/share/perl5/PVE/Network.pm line 18. > BEGIN failed--compilation aborted at /usr/share/perl5/PVE/Network.pm line 18. > Compilation failed in require at /usr/share/perl5/PVE/INotify.pm line 15. > BEGIN failed--compilation aborted at /usr/share/perl5/PVE/INotify.pm line 15. > Compilation failed in require at /usr/share/perl5/PVE/Cluster.pm line 15. > BEGIN failed--compilation aborted at /usr/share/perl5/PVE/Cluster.pm line 15. > Compilation failed in require at /usr/share/perl5/PVE/CLI/pvesh.pm line 9. > BEGIN failed--compilation aborted at /usr/share/perl5/PVE/CLI/pvesh.pm line > 9. > Compilation failed in require at /usr/bin/pvesh line 6. > BEGIN failed--compilation aborted at /usr/bin/pvesh line 6 > > > > I wonder if it couldn'be be better to move the tap/veth management directly > in sdn plugins and independent of historic code, > if somebody want to create a plugin for dpdk or others vswitch for example. > > what do you think about this ? sounds OK, but I'd for now keep the "old" code here and just let SDN chain-call it, if required. We could for now do the "has SDN" in th e VM/CTs network hooks, else we'd have to make pve-network a default package dependency now, which may be a bit early yet? > > I'll need to patch qemu-server on tap plug/unplug, vm stop/start, lxc > stop/start . > (That's why I had only do this small patch first, directly in tap|veth > plug|create, but I'm not too happy with this require bug) haha, gosh, I should really read your mail to the end before starting to answer, I think I had to re-write it two times solely due to that. Asking question/making points you already answered.. ^^ Anyway, let's go your proposal way - but leave the existing create methods for now in common, I'd only move them fully over once we've pve-network default and we ensured that moving does not break the PMG or the like. cheers, Thomas _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
