--- Begin Message ---
Package: cloud.debian.org
Severity: grave
Hi,
Testing to start the OpenStack image (well, the "genericcloud" image), I
couldn't login into it, because there isn't any metadata service configured
in it.
After adding this:
# cat /etc/cloud/cloud.cfg.d/90_dpkg.cfg
datasource_list: [ NoCloud, AltCloud, ConfigDrive, OpenStack, CloudStack, DigitalOcean, Ec2, MAAS, OVF, GCE, None ]
which is what the legacy OpenStack image does, and rebooting the instance, I
could login without any problem.
After that, it appears that /etc/hosts wasn't configued at all with the
hostname, therefore, the hostname couldn't be resolved even within the VM
itself. I'm not sure if this is related or not, however.
IMO, this is of severity grave, because the image is not usable without a
tweak (ie: impossible to login).
Cheers,
Thomas Goirand (zigo)
--- End Message ---
--- Begin Message ---
Hi Bastian,
Thanks for your answer.
On 10/27/20 6:50 PM, Bastian Blank wrote:
> On Tue, Oct 27, 2020 at 04:54:13PM +0100, Thomas Goirand wrote:
>> Testing to start the OpenStack image (well, the "genericcloud" image), I
>> couldn't login into it, because there isn't any metadata service configured
>> in it.
>
> This is incorrect. The package uses
> /lib/systemd/system-generators/cloud-init-generator to generate a
> config. This works in general:
>
> | $ cat /run/cloud-init/cloud.cfg
> | datasource_list: [ Azure, None ]
>
> So, please provide more information.
Hi,
Looking at the logs, I could see the issue was a ConnectTimeoutError
contacting the metadata server on http://169.254.169.254/openstack, so
that probably was a problem in my OpenStack setup, somehow. That's
surprising, because I tried spawning 10 other instances, and none failed.
I'm therefore closing the bug, sorry for the noise. I should have
checked the logs in the first place...
>> After that, it appears that /etc/hosts wasn't configued at all with the
>> hostname, therefore, the hostname couldn't be resolved even within the VM
>> itself. I'm not sure if this is related or not, however.
>
> Show logs? /run/cloud-init/cloud-init-generator.log for example.
This still is a problem, even when the metadata are fetched. So this
would deserve a separate bug, I guess. Though I'm not there yet in terms
of thinking how to fix or if we should do anything for it. Let me expand...
In the logs, I can see:
Configuration option 'manage_etc_hosts' is not set, not managing
/etc/hosts in module update_etc_hosts
Adding:
# cat /etc/cloud/cloud.cfg.d/03_zigo.cfg
manage_etc_hosts: true
made it add a 127.0.1.1 entry with the hostname, though this deletes any
other entry I would manually add, as per the cloud-init doc says (and I
tested that fact).
So I wonder how we can fix it, ie that a 127.0.1.1 is added by default,
at least to get the hostname resolvable (and avoid a warning when
sudoing to root).
>> IMO, this is of severity grave, because the image is not usable without a
>> tweak (ie: impossible to login).
>
> Severities have no real meaning for non-package resources.
Probably you really mean "no real life consequence"? :)
Hopefully, you'll agree that sorting issue by severity can still be
handy at times.
> And the same
> mechanism clearly works on Azure and EC2 without problems, so it would
> be only "important".
So, Azure is more important? :) </troll>
Thomas
--- End Message ---