On Wed, Apr 3, 2019 at 4:14 AM Eduardo Otubo <[email protected]> wrote:
> Hello all, > > So, I'd like to talk about a behavior that's impacting some customers > running > RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=1593010 > > I've been discussing this issue with Ryan Harper and Ryan Mccabe, and all > the > possibilities I posted on that bugzilla are basically the result of those > discussions. > > tl;dr: The problem consists in resetting the network configuration to > default > whenever the CD image used is removed, hence the data source is removed > and a > new instance-id is generated. Besides persisting the configuration after > removing the data source, customers also want it to change whenever a new > data > source is plugged in. > > 1) Passing argument on kernel line is not an option because we can't change > what's inside customer's vm. > > 2) Using `manual_cache_clean' is not an option because in this case > customer > will have to manually clean the cache when a new data source is plugged. > > I'd like to reach out on this mailing list and hear your opinions before I > start > to code a solution for this. Is there any other option left that could > comply > with this corner case? Attach data source and persist instance-id until a > new data > source is plugged? > I think comment 38 (Config drive only presented on first boot) is the core issue here. One thing I'm curious about; the comment suggests that the cdrom is no longer present; This should mean that cloud-init disables itself; I wonder if this is related to the version of cloud-init you have, 0.79. Current cloud-init uses a systemd-generator detect if it's booting on a system or platform which is providing a datasource. In the scenario from the bug, it initially provides a cdrom with the NoCloud datasource and then the cdrom is removed. After rebooting the VM, the cdrom is no longer present, cloud-init generator will not find the cdrom with NoCloud seed and it will disable itself (no need to mask services). If the cdrom is provided again with a new instance-id cloud-init will run as if it's a new instance. You should be able to test this out if you use cloud-init from the daily copr repo[1] and see if this does not resolve your issue. 1. https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ > > Regards, > > -- > Eduardo Otubo > > Red Hat GmbH,http://www.de.redhat.com/, Sitz: Grasbrunn, > Handelsregister: Amtsgericht München, HRB 153243, > Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander > -- > Mailing list: https://launchpad.net/~cloud-init > Post to : [email protected] > Unsubscribe : https://launchpad.net/~cloud-init > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~cloud-init Post to : [email protected] Unsubscribe : https://launchpad.net/~cloud-init More help : https://help.launchpad.net/ListHelp
