cloud-init team mailing list archive

[Robert Schweikert <rjschwei@xxxxxxxx>]

Hi,

On 4/9/19 10:04 AM, Ryan Harper wrote:
> 
> 
> On Tue, Apr 9, 2019 at 8:44 AM Eduardo Otubo <otubo@xxxxxxxxxx
> <mailto: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.

If the data source is set on the kernel comandline then cloud-init will
not be disabled by the generator. This feature helps to work around the
issue with the generator race condition,
https://bugs.launchpad.net/cloud-init/+bug/1810859

Later,
Robert



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

-- 
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
Distinguished Architect                       LINUX
Technical Team Lead Public Cloud
rjschwei@xxxxxxxx
IRC: robjo