cloud-init team mailing list archive

[Eduardo Otubo <otubo@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: PGP signature