cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

On Wed, Apr 3, 2019 at 4:14 AM Eduardo Otubo <otubo@xxxxxxxxxx> 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     : cloud-init@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cloud-init
> More help   : https://help.launchpad.net/ListHelp
>