cloud-init team mailing list archive

[Eduardo Otubo <otubo@xxxxxxxxxx>]

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.

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

Attachment: signature.asc
Description: PGP signature