cloud-init team mailing list archive

[Eduardo Otubo <otubo@xxxxxxxxxx>]

Also, our QE reported that that issue is still present even with our 18.5
rebase. Is there any additional configuration/steps in order to bypass this
issue?

On 09/04/2019 - 09:21:18, Scott Moser wrote:
> 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

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