cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

On Tue, Apr 9, 2019 at 8:44 AM Eduardo Otubo <otubo@xxxxxxxxxx> wrote:

> 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?
>
>
Not that I'm aware of.  I've verified the behavior on our Ubuntu images.
In the case that cloud-init ran when you didn't provide any datasource
examining /run/cloud-init/cloud-init-generator.log  and
/run/cloud-init/ds-identify.log
will have information on what datasource it found a from where.

Ryan


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
>