cloud-init team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

Its unfortunate that cloud-init differs in behavior with and without
the systemd generator running.  Ideally in cases where there was no
datasource present cloud-init would have the same behavior independent
of its presence.  Its doable, just work to do.

On Fri, Apr 5, 2019 at 4:46 AM Eduardo Otubo <otubo@xxxxxxxxxx> wrote:
>
> On 04/04/2019 - 09:13:34, Ryan Harper wrote:
> > 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).
>
> Awesome, I'll prepare the 18.5 rebase package and will have it tested. Thanks
> for the info Ryan.
>
> --
> 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