Re: [Openstack] cc_ssh.py warning (cloud-init issue resolved)
Original Message Subject:Re: [Openstack] cc_ssh.py warning (cloud-init issue resolved) Date: Fri, 07 Jun 2013 12:31:45 -0700 From: Justin Chiu j.c...@cern.ch To: Steven Hardy sha...@redhat.com Thanks Steve. cloud-init-0.6.3-0.12.bzr532.el6.noarch python-boto-2.5.2-3.el6.noarch (grabbed from EPEL) Some good and bad news. The issue of cloud-init not being able to obtain metadata seems to have resolved itself. Launched a dozen instances and they all grabbed the metadata just fine. I will post if I run into the metadata issue again... -- I've run into a (not so critical) issue with one of the scripts: cc_ssh.py[WARNING]: applying credentials failed! Further down in the log: ec2: # ec2: -BEGIN SSH HOST KEY FINGERPRINTS- ec2: 1024 XX:XX:... /etc/ssh/ssh_host_dsa_key.pub (DSA) ec2: 2048 XX:XX:... /etc/ssh/ssh_host_key.pub (RSA1) ec2: 2048 XX:XX:... /etc/ssh/ssh_host_rsa_key.pub (RSA) ec2: -END SSH HOST KEY FINGERPRINTS- ec2: # -BEGIN SSH HOST KEY KEYS- *my keys* -END SSH HOST KEY KEYS- So it seems like the keys are applied. Furthermore, I can log-in with the corresponding private key just fine. Is there some non-critical incompatibility between the cloud-init scripts and SSH paths, etc...that I have overlooked? Thanks for your help, Justin On 2013-06-06 2:27 AM, Steven Hardy wrote: On Wed, Jun 05, 2013 at 09:25:17AM -0700, Justin Chiu wrote: Hi all, I sent this message out a few days ago. I am still trying to figure out what is going on. Any advice would be much appreciated. -- I am having some issues with cloud-init being unable to contact the metadata server. cloud-init built into a base Scientific Linux 6.4 image with Oz. Any ideas on what might be the cause? Can you confirm the version of cloud-init and python-boto in your image? I found on Fedora that cloud-init 0.7.x only works with newer ( 2.6.0) boto versions. Getting the wrong combination can lead to the sort of problems you're seeing IME. Steve ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] cloud-init on SL6 unable to access metadata server
--level=info firewall --disabled authconfig --enableshadow --enablemd5 selinux --disabled timezone --utc America/Vancouver bootloader --location=mbr --append=console=tty0 console=ttyS0,115200 zerombr yes clearpart --all part /boot --fstype ext4 --size=200 part pv.2 --size=1 --grow volgroup VolGroup00 --pesize=32768 pv.2 logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=768 --grow --maxsize=1536 logvol / --fstype ext4 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow reboot %packages @base %post Template TDL: template namesl64wrepo_onbootnet_x86_64/name disk size2/size /disk os nameSL-6/name version4/version archx86_64/arch install type='iso' isofile:///mnt/scratch/SL-64-x86_64-2013-03-18-Install-DVD.iso/iso /install /os descriptionSL 6.4wrepoonbootnet template/description repositories repository name='epel-6' urlhttp://download.fedoraproject.org/pub/epel/6/x86_64/url signedFalse/signed persistedTrue/persisted /repository /repositories packages package name='cloud-init'/ /packages /template -- Justin ChiuTRIUMF ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] cloud-init on SL6 unable to access metadata server
On 2013-06-03 10:28 AM, George Mihaiescu wrote: Try manually removing the route to 169.254.0.0 from inside the instance: route del -net 169.254.0.0/16 dev eth0 And then test again with curl -m 10 -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key; curl could not connect to host. Interestingly, I can ping to 169.254.169.254 (from within the instance)... -Original Message- From: Openstack [mailto:openstack-bounces+george.mihaiescu=q9@lists.launchpad.net] On Behalf Of Justin Chiu Sent: Monday, June 03, 2013 1:12 PM To: openstack@lists.launchpad.net Subject: [Openstack] cloud-init on SL6 unable to access metadata server Hi all, I am having some issues with cloud-init being unable to contact the metadata server. cloud-init built into a base Scientific Linux 6.4 image with Oz. Any ideas on what might be the cause? Starting cloud-init: ci-info: lo: 1 127.0.0.1 255.0.0.0 . ci-info: eth0 : 1 10.0.100.3 255.255.255.0 fa:16:3e:00:55:b3 ci-info: route-0: 10.0.100.0 0.0.0.0 255.255.255.0 eth0 U ci-info: route-1: 169.254.0.0 0.0.0.0 255.255.0.0 eth0 U ci-info: route-2: 0.0.0.0 10.0.100.1 0.0.0.0 eth0 UG cloud-init start running: Fri, 31 May 2013 21:33:13 +. up 16.56 seconds DataSourceEc2.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [50/120s]: url error [timed out] ... DataSourceEc2.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: url error [timed out] DataSourceEc2.py[CRITICAL]: giving up on md after 120 seconds From within the VM, I can ping 169.254.169.254 but curl http://169.254.169.254 produces no output. cloud-init starts up successfully from Ubuntu Cloud images, gets metadata OK. curl http://169.254.169.254 produces the correct output (metadata/ 2009.../ etc...) iptables -L -n -t nat output of the controller+compute node: Chain nova-network-PREROUTING (1 references) target prot opt source destination DNAT tcp -- 0.0.0.0/0169.254.169.254 tcp dpt:80 to:a.b.c.8:8775 Openstack specs: Folsom 2012.2.4-1 release from EPEL 6, installed on two SL6.4 base installs. One cloud controller+compute node and the other purely compute node. FlatDHCP, eth0 public, eth1 flat (both eth1 of each node are connected via a switch, independent from eth0). nova.conf on controller+compute node (IP a.b.c.8 and hostname t1-pps05): [DEFAULT] logdir = /var/log/nova state_path = /var/lib/nova lock_path = /var/lib/nova/tmp volumes_dir = /etc/nova/volumes dhcpbridge = /usr/bin/nova-dhcpbridge dhcpbridge_flagfile = /etc/nova/nova.conf force_dhcp_release = True injected_network_template = /usr/share/nova/interfaces.template libvirt_nonblocking = True libvirt_inject_partition = -1 network_manager = nova.network.manager.FlatDHCPManager iscsi_helper = tgtadm sql_connection = mysql://nova:XXX@t1-pps05/nova compute_driver = libvirt.LibvirtDriver firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver rpc_backend = nova.openstack.common.rpc.impl_qpid rootwrap_config = /etc/nova/rootwrap.conf flat_interface = eth1 public_interface = eth0 volume_api_class = nova.volume.cinder.API enabled_apis = ec2,osapi_compute,metadata auth_strategy = keystone my_ip = a.b.c.8 fixed_range = 10.0.100.0/24 flat_network_bridge = br100 flat_injected = False novncproxy_host = 0.0.0.0 novncproxy_port = 6080 novncproxy_base_url = http://t1-pps05:6080/vnc_auto.html vnc_enabled = True vncserver_listen = a.b.c.8 vncserver_proxyclient_address = a.b.c.8 [keystone_authtoken] admin_tenant_name = admin admin_user = admin admin_password = XXX auth_host = t1-pps05 auth_port = 35357 auth_protocol = http signing_dir = /tmp/keystone-signing-nova nova.conf on compute only node (a.b.c.9, t1-pps06): [DEFAULT] logdir = /var/log/nova state_path = /var/lib/nova lock_path = /var/lib/nova/tmp volumes_dir = /etc/nova/volumes dhcpbridge = /usr/bin/nova-dhcpbridge dhcpbridge_flagfile = /etc/nova/nova.conf force_dhcp_release = True injected_network_template = /usr/share/nova/interfaces.template libvirt_nonblocking = True libvirt_inject_partition = -1 network_manager = nova.network.manager.FlatDHCPManager iscsi_helper = tgtadm sql_connection = mysql://nova:XXX@t1-pps05/nova compute_driver = libvirt.LibvirtDriver firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver rpc_backend = nova.openstack.common.rpc.impl_qpid rootwrap_config = /etc/nova/rootwrap.conf flat_interface = eth1 public_interface = eth0 volume_api_class = nova.volume.cinder.API enabled_apis = ec2,osapi_compute,metadata auth_strategy = keystone my_ip = a.b.c.9 fixed_range = 10.0.100.0/24 flat_network_bridge = br100 flat_injected = False novncproxy_host = 0.0.0.0 novncproxy_port = 6080 novncproxy_base_url = http://t1-pps06:6080/vnc_auto.html vnc_enabled = True vncserver_listen = a.b.c.9 vncserver_proxyclient_address = a.b.c.9 s3_host = a.b.c.8 ec2_host = a.b.c.8 qpid_hostname
[Openstack] fixed_range='' results in critical error when starting nova-network
Hello all, I am trying to resolve a critical error when fixed_range='' is specified in nova.conf. The error is resolved if I set fixed_range manually, i.e. fixed_range= 10.0.0.0/24 VM launching via Horizon and guest networking is fully operational with the above fix. Similar error but different cause, https://lists.launchpad.net/openstack/msg04588.html I am using FlatDHCP networking between two Openstack nodes running the Folsom release (from EPEL) on a base installation of Scientific Linux 6.4. I followed the guide from Red Hat Openstack Getting Started guide to prepare Keystone, Glance and Horizon and the Compute manual for setting up the networking. Controller node (Keystone, Nova, Glance, Horizon) sl1: 10.168.2.122 Compute only node compute1: 10.168.2.126 Iptables disabled (service iptables stop on both nodes). Every service except nova-network seems to be operational, judging from openstack-status and service --status-all | grep openstack. nova.conf snippet on the controller node: network_manager = nova.network.manager.FlatDHCPManager flat_interface = eth2 public_interface = eth1 my_ip = 10.168.2.122 #fixed_range=10.0.0.0/24 #fixed_range='' flat_network_bridge = br100 flat_injected = False nova.conf snippet on the compute only node: network_manager = nova.network.manager.FlatDHCPManager flat_interface = eth1 public_interface = eth0 my_ip = 10.168.2.126 #fixed_range = 10.0.0.0/24 #fixed_range = '' flat_network_bridge = br100 flat_injected = False s3_host = 10.168.2.122 ec2_host = 10.168.2.122 qpid_hostname = 10.168.2.122 metadata_host = 10.168.2.122 ec2_dmz_host = 10.168.2.122 glance_api_servers=sl1:9292 nova-network.log (identical on both nodes): 2013-05-22 16:21:17 18884 AUDIT nova.service [-] Starting network node (version 2012.2.3-1.el6) 2013-05-22 16:21:22 18884 CRITICAL nova [-] Unexpected error while running command. Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iptables-restore -c Exit code: 2 Stdout: '' Stderr: Bad argument `SNAT'\nError occurred at line: 27\nTry `iptables-restore -h' or 'iptables-restore --help' for more information.\n Any suggestions on how to resolve this issue would be much appreciated! Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
