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

David Raddatz draddatz at sgi.com
Fri Nov 8 20:27:17 UTC 2013


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

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