[rhos-list] cloud-init configuration for ssh access

David Raddatz draddatz at sgi.com
Fri Nov 8 21:51:15 UTC 2013


> -----Original Message-----
> From: Steven Dake [mailto:sdake at redhat.com]
> Sent: Friday, November 08, 2013 3:03 PM
> To: David Raddatz; Lars Kellogg-Stedman
> Cc: Perry Myers; rhos-list at redhat.com
> Subject: Re: [rhos-list] cloud-init configuration for ssh access
> 
> On 11/08/2013 01:27 PM, David Raddatz wrote:
> > Hi, Guys,
> >
> > Thanks for following up on this... Regarding the instance directory that was
> created...  Here's what I did to recreate the error (if it helps with any debug):
> >
> > It's been awhile but I'm pretty sure that /var/lib/cloud/instance directory
> was getting created after I rebooted my VM image right after installing cloud-
> init but BEFORE I uploaded it to glance (I was rebooting the VM image just to
> make sure it would still boot after installing cloud-init).
> >
> > Here are the steps I did to recreate the problem after working with
> > Lars
> > - create VM and install RHEL 6.4 and set up with other files/software
> > - install/configure cloud-init on VM
> >    If you check /var/lib/cloud, it'll be empty.  At this point, ssh to the image
> works fine.
> > - reboot VM (my paranoid reboot thinking I needed to check that the VM
> would still reboot)
> >    If you check /var/lib/cloud now it will have the instance directory and
> some other files/directories
> >    Now at this point, ssh to the image is broken even before preparing and
> uploading it to glance - I get the Permission denied message.
> > - shutdown VM
> > - run virt-sysprep on image (per recommendation in docs)
> > - upload to glance and launch instance using the defined keypair
> > - trying to use ssh -i with the same keypair results in Permission
> > denied same as above
> >
> > I'm fairly certain the image I sent to Lars was an image created by using
> these steps.  So the filesystem I sent to Lars was one that had the
> /var/lib/cloud/instance directory because I had rebooted it and it was the
> problem image that I needed help with.
> >
> > Hope that helps,
> > Dave
> Dave,
> 
> Can you add your reproducer to:
> https://bugzilla.redhat.com/show_bug.cgi?id=1025749

Hi, Steve, I would but my id (my email address) doesn't have access to the bugzilla report.

Dave

> 
> Even if Lars can't reproduce it, better to have the reproducer in bugzilla then
> lost in a mailing list :)
> 
> Regards
> -steve
> 
> >> -----Original Message-----
> >> From: rhos-list-bounces at redhat.com [mailto:rhos-list-
> >> bounces at redhat.com] On Behalf Of Steven Dake
> >> Sent: Friday, November 08, 2013 1:36 PM
> >> To: Lars Kellogg-Stedman
> >> Cc: Perry Myers; rhos-list at redhat.com
> >> Subject: Re: [rhos-list] cloud-init configuration for ssh access
> >>
> >> On 11/08/2013 12:16 PM, Lars Kellogg-Stedman wrote:
> >>> On Fri, Nov 08, 2013 at 12:08:15PM -0700, Steven Dake wrote:
> >>>> The tl;dr version is the code is working as intended.  Recommend
> >>>> more
> >> docs.
> >>> I think the actual situation was something different.
> >>>
> >>> In the filesystem image Dave sent to me, something had created a
> >>> *directory* called /var/lib/cloud/instance.  Normally this is a
> >>> symlink into instances/<instance-id>, and having this a directory
> >>> was preventing cloud-init from creating the symlink and was making
> >>> it fall over.
> >>>
> >>> Removing this directory allowed cloud-init to proceed as intended.
> >>> I was not able to reproduce this failure mode in my own testing, so
> >>> I'm not sure how that directory go there.
> >> I see.  If cloud-init spits out some kind of odd error like "couldn't
> >> create symlink, giving up", then that sounds like a bug that needs
> >> root-cause analysis.  IIRC the lock files are stored in that instance
> >> directory, but they may actually have been in the symlinked instance-id
> dirs.
> >>
> >> In recommend opening a bug so we can track logs/progress/image
> >> contents as opposed to using a mailing list to triage bugs.  If we
> >> can figure out how the image was created, it is something that can be
> reproduced.
> >>
> >> But without a reproducer, the problem may go unsolved.
> >>
> >> Regards
> >> -steve
> >>
> >>>> The cloud-init code is designed to only run the cloud config
> >>>> modules once by default.
> >>> This wasn't an issue with the per-instance semaphores.
> >>>
> >> _______________________________________________
> >> rhos-list mailing list
> >> rhos-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/rhos-list





More information about the rhos-list mailing list