Sounds good to me too- I haven't come to any other conclusions that will sanely work by default without introducing more complexity in instance initialization logic (whether that is part of cloud-init or otherwise). I was hoping we had a better solution via systemd-networkd.
----- Zach Marano [email protected] On Tue, Jun 6, 2017 at 1:22 PM, kuLa <[email protected]> wrote: > On 2017-06-02 16:53:24, Emmanuel Kasper wrote: > > >> Generally, to the debian-cloud folks, what are your thoughts here for > > >> Debian cloud images. The possibility that PCI devices can change is > always > > >> on the table and we shouldn't assume it can't happen in any given > > >> virtualization environment. > > > > > > I can't speak for all cloud providers but bootstrap-vz disables > > persistent nic device names via net.ifnames=0 boot param > > see : > > https://github.com/andsens/bootstrap-vz/blob/ > f71eac2c390e67ebac4e237d937481ae1909e800/bootstrapvz/common/ > tasks/grub.py#L229 > > > > this seems a good thing if the platform you build is not the one you run > > > > I do the same for Vagrant Virtualbox images, as I build with qemu for a > > Virtual Box target and nic pci position on bus is different > > A few days back we had had discussion about this subject on IRC in regards > of > AWS images and I think we reached conclusion to use **net.ifnames=0** to > sort > it out (at least for now). > > So probably the same should be done for GCP images and in regards of > discrepancies between default Debian image and Cloud image we just need to > document it and go with it as without fixing this issue IMO images are > partly > broken. > -- > > |_|0|_| | > |_|_|0| "Panta rei" | > |0|0|0| -------- kuLa -------- | > > gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 > 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 >
