>>So IMO it's fine if the switch from ifupdown1 to ifupdown2 requires >>some manual intervention.
ok >>(basically our config writer would have to distinguish between which >>package is currently installed when writing the file, I was thinking also to distinguish if ifupdown2 is installed, if we want to add some new ifupdown2 features config from gui. (vxlan, ipv4/ipv6 dual stack on same interface, network reloading, ...) >>(I'd also be fine with doing nothing though as long as we have no hard >>dependency on the package as it's fully optional then and users need to >>follow the docs or expect breakage, as usual...) except ovs config, I don't have seen other breaking change. But nothing complex to manually change following a small doc. ----- Mail original ----- De: "Wolfgang Bumiller" <[email protected]> À: "aderumier" <[email protected]> Cc: "dietmar" <[email protected]>, "pve-devel" <[email protected]> Envoyé: Lundi 18 Juin 2018 13:27:28 Objet: Re: [pve-devel] [PATCH ifupdown2] allow address on vlan aware bridge On Mon, Jun 18, 2018 at 01:00:31PM +0200, Alexandre DERUMIER wrote: > > I don't known if we could update pve-common management to cleanup current > > config, > > >>yes. it's compatible, so why not? This quoting confuses some of my email clients. > > > or make a post-install script in ifupdown2 to update config ? > > >>We only require this if we cannot support reading both formats. > > > Ok thanks. Indeed, it's working with both ifupdown/ifupdown2. > > > But I don't known how to update config (transparently) for users ? (This > don't need /etc/network/interfaces.new and reboot) Not transparently probably, as we already do not handle the entire configuration (/etc/network/interfaces.d/ files in particular). So IMO it's fine if the switch from ifupdown1 to ifupdown2 requires some manual intervention. So there could be a post-install script generating a new '.new' file (basically our config writer would have to distinguish between which package is currently installed when writing the file, then this would just be a 'write(read())' call), and then perhaps use a dialog to show the user the new config and accept or abort...? (I'd also be fine with doing nothing though as long as we have no hard dependency on the package as it's fully optional then and users need to follow the docs or expect breakage, as usual...) _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
