cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

On Thu, Apr 4, 2019 at 12:02 AM Eduardo Otubo <otubo@xxxxxxxxxx> wrote:

> On 03/04/2019 - 09:17:23, Ryan Harper wrote:
> > 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/
>
> Can you pinpoint the exact commit that introduces this feature? Would it
> be this
> one?
>
> commit 09dcecf37628c5809ae21d7785693cb7358ca94c
> Author: Robert Schweikert <rjschwei@xxxxxxxx>
> Date:   Mon Jan 28 17:51:57 2019 +0000
>
>     systemd: Render generator from template to account for system
> differences.
>
>     The systemd generator used had a hard coded path for the location
> target
>     file to create.  This path does not apply to all distributions.
>     Make the generator and template to have the path set during build time.
>
> We're conducting a rebase to 18.5 so it would be easy to possibly backpor
> this.
>

ds-identify has been in cloud-init since early 2017, the initial commit is
here[1].
There have been many improvements and changes since then; it's not something
I would look to cherry pick.     Moving to 18.5 will be sufficient to
enable the
basic functionality you'll need (disabling if no datasource/platform
detected).

1.
commit 9698b0ded3d7e72f54513f248d8da41e08472f68
Author: Scott Moser <smoser@xxxxxxxxxx>
Date:   Sat Feb 4 02:24:55 2017 +0000

    Add tools/ds-identify to identify datasources available.

    ds-identify is run here from the generator.  If ds-identify does
    not see any datasources, it can completely disable cloud-init.
    The big value in this is that if there is no datasource, no python
    will ever be loaded, and cloud-init will be disabled.o

    The default policy being added here is:
      search,found=all,maybe=all,notfound=disabled

    That means:
      - enable (in 'datasource_list') all sources that are found.
      - if none are found, enable all 'maybe'.
      - if no maybe are found, then disable cloud-init.

    On platforms without DMI (everything except for aarch64 and x86),
    the default 'notfound' setting is 'enabled'.  This is because many of
    the detection mechanisms rely on dmi data, which is present only on
    x86 and aarch64.




>
> Best 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
>