From Hao.Chen at NRCan-RNCan.gc.ca Thu Aug 1 18:50:48 2013 From: Hao.Chen at NRCan-RNCan.gc.ca (Chen, Hao) Date: Thu, 1 Aug 2013 18:50:48 +0000 Subject: [rhos-list] Validating the installation In-Reply-To: <471B1A3D-CD02-46DA-8E4C-5D1E0850AEA3@redhat.com> References: <76CC67FD1C99DB4DB4D43FEF354AADB647015BE8@S-BSC-MBX2.nrn.nrcan.gc.ca> <471B1A3D-CD02-46DA-8E4C-5D1E0850AEA3@redhat.com> Message-ID: <76CC67FD1C99DB4DB4D43FEF354AADB64701652B@S-BSC-MBX2.nrn.nrcan.gc.ca> Hi Rhys, Thanks for the suggestions. But I still could not reach the external network from the internal subnet even though the interface status became "Active". The screenshot of the network topology is attached. The internal network (192.168.1.0/24) is working well. 10.2.0.1 is the external gate way. From the internal subnet I can ping the gateway 192.168.1.1/10.2.0.1, but just cannot reach outside and the 10.2. network. [root at cloud1 ~(keystone_admin)]# quantum port-show 38eea51a-2956-4168-aaeb-e52a3b5e9505 (internal interface) +----------------------+------------------------------------------------------------------------------------+ | Field | Value | +----------------------+------------------------------------------------------------------------------------+ | admin_state_up | True | | binding:capabilities | {"port_filter": true} | | binding:vif_type | ovs | | device_id | 946402dd-cefc-4317-b640-a2d2f53cdd9e | | device_owner | network:router_interface | | fixed_ips | {"subnet_id": "182c64c0-9671-4c48-b50c-91e8bb24ccbd", "ip_address": "192.168.1.1"} | | id | 38eea51a-2956-4168-aaeb-e52a3b5e9505 | | mac_address | fa:16:3e:d4:77:39 | | name | | | network_id | 02af0ab9-6ef1-4250-be48-feb36cc98d00 | | security_groups | | | status | ACTIVE | | tenant_id | 35caeda3b4d84d1582e675c2f871a00c | +----------------------+------------------------------------------------------------------------------------+ [root at cloud1 ~(keystone_admin)]# quantum port-show 22ed85aa-63f8-4cce-9cfb-d75409c45014 (external interface) +----------------------+---------------------------------------------------------------------------------+ | Field | Value | +----------------------+---------------------------------------------------------------------------------+ | admin_state_up | True | | binding:capabilities | {"port_filter": true} | | binding:vif_type | ovs | | device_id | 946402dd-cefc-4317-b640-a2d2f53cdd9e | | device_owner | network:router_interface | | fixed_ips | {"subnet_id": "b41f60d2-d880-48dc-8588-60bafe712180", "ip_address": "10.2.0.1"} | | id | 22ed85aa-63f8-4cce-9cfb-d75409c45014 | | mac_address | fa:16:3e:20:14:44 | | name | | | network_id | b343ced9-89a9-43dc-bea9-861f9bf6123f | | security_groups | | | status | ACTIVE | | tenant_id | 35caeda3b4d84d1582e675c2f871a00c | +----------------------+---------------------------------------------------------------------------------+ When running "ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e ssh hchen at 192.168.1.102" I did not get any response. Any suggestions? Thanks, Hao -----Original Message----- From: Rhys Oxenham [mailto:roxenham at redhat.com] Sent: July 30, 2013 17:40 To: Chen, Hao Cc: rhos-list at redhat.com Subject: Re: [rhos-list] Validating the installation Hi Hao, On 31 Jul 2013, at 00:25, "Chen, Hao" wrote: > Greetings, > > (1) After creating an instance with rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2, a KVM Guest Image downloaded fromhttps://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952, I was asked for the Login ID and Password for the console access. Does anyone know the Login info? Please see: http://rhn.redhat.com/errata/RHSA-2013-0849.html (https://bugzilla.redhat.com/show_bug.cgi?id=964299) As far as I'm aware the image expects you to inject an SSH key using the metadata service in OpenStack and that the default root password is locked. Once connected into the instance via the SSH key it would be possible to reset the root password there. But hopefully others will clarify the situation. If this is not an option for you, you may want to take the image and use libguestfs/guestfish to make modifications to the image before uploading into Glance. For example, set the root password to something specific to your requirements, but please note that the image will likely disable password logins via sshd, so this too will have to be changed. If this is ONLY for testing and will not be used in production then I'd just reset the root password to blank as it's quick and easy to get the image up and running, below is just an example... # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PasswordAuthentication.*/PasswordAuthentication yes/' # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PermitRootLogin.*/PermitRootLogin yes/' # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PermitEmptyPasswords.*/PermitEmptyPasswords yes/' # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^root:.*?:/root::/' # glance image-create .... I've not tested the above, it may require further steps for it to work as expected. I'll try this out in the morning. > > (2) I am having trouble with the Router Interfaces. The internal interface is working " 192.168.1.1 ACTIVE Internal Interface", but the status of the external interface always shows Down "10.2.0.193 DOWN External Gateway". Very grateful for any suggestions. I too have this, my internal interface (as in the internal port on the router) is shown as "UP" yet the external gateway port is "DOWN". I don't actually have any problems though... [root at openstack-controller ~(keystone_admin)]$ quantum port-show 11f2d170-baec-461f-bc30-b1f880132a03 +----------------------+---------------------------------------------------------------------------------------+ | Field | Value | +----------------------+---------------------------------------------------------------------------------------+ | admin_state_up | True | | binding:capabilities | {"port_filter": true} | | binding:vif_type | ovs | | device_id | 6bea3ee4-47d6-4a3e-a9da-c82fed18baa0 | | device_owner | network:router_gateway | | fixed_ips | {"subnet_id": "89ee4bc1-073e-4ccd-a108-6c839dad011d", "ip_address": "192.168.122.10"} | | id | 11f2d170-baec-461f-bc30-b1f880132a03 | | mac_address | fa:16:3e:cd:2b:20 | | name | | | network_id | 7382ead9-faba-405a-a78f-404c236c9334 | | security_groups | | | status | DOWN | | tenant_id | | +----------------------+---------------------------------------------------------------------------------------+ Yet the L3 agent works perfectly for me... [root at openstack-controller ~(keystone_admin)]$ ip netns exec qrouter-6bea3ee4-47d6-4a3e-a9da-c82fed18baa0 ssh cirros at 30.0.0.4 cirros at 30.0.0.4's password: $ ping 8.8.8.8 -c 3 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=127 time=29.141 ms 64 bytes from 8.8.8.8: seq=1 ttl=127 time=32.105 ms 64 bytes from 8.8.8.8: seq=2 ttl=127 time=27.258 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 27.258/29.501/32.105 ms Do things work for you like above, or are you seeing problems? Cheers, Rhys > > Thanks, > Hao > > > _______________________________________________ > rhos-list mailing list > rhos-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhos-list -------------- next part -------------- A non-text attachment was scrubbed... Name: networktopology.png Type: image/png Size: 92133 bytes Desc: networktopology.png URL: From roxenham at redhat.com Thu Aug 1 23:08:06 2013 From: roxenham at redhat.com (Rhys Oxenham) Date: Fri, 2 Aug 2013 00:08:06 +0100 Subject: [rhos-list] Validating the installation In-Reply-To: <76CC67FD1C99DB4DB4D43FEF354AADB64701652B@S-BSC-MBX2.nrn.nrcan.gc.ca> References: <76CC67FD1C99DB4DB4D43FEF354AADB647015BE8@S-BSC-MBX2.nrn.nrcan.gc.ca> <471B1A3D-CD02-46DA-8E4C-5D1E0850AEA3@redhat.com> <76CC67FD1C99DB4DB4D43FEF354AADB64701652B@S-BSC-MBX2.nrn.nrcan.gc.ca> Message-ID: <03E7C84E-9040-4E82-B406-1BBE0BA45A07@redhat.com> Hi Hao, To clarify, you've got two issues now? 1) From within your instances you cannot get access the outside world, i.e. it won't go any further than 10.2.0.1 (or 192.168.1.1)? What's the output of? # ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e route # ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e ip a I am wondering whether the gateway is configured properly on your external network so it knows how to route things accordingly. 2) You cannot use the namespace to SSH into your instances via the tenant-network address, e.g. 192.168.1.102? This shouldn't be affected by security group rules as we're not using iptables/NAT if going via the tenant network. Does it also fail with a ping? Thanks Rhys -- Rhys Oxenham Cloud Solution Architect, Red Hat UK e: roxenham at redhat.com m: +44 (0)7866 446625 On 1 Aug 2013, at 19:50, "Chen, Hao" wrote: > Hi Rhys, > > Thanks for the suggestions. But I still could not reach the external network from the internal subnet even though the interface status became "Active". The screenshot of the network topology is attached. The internal network (192.168.1.0/24) is working well. 10.2.0.1 is the external gate way. From the internal subnet I can ping the gateway 192.168.1.1/10.2.0.1, but just cannot reach outside and the 10.2. network. > > [root at cloud1 ~(keystone_admin)]# quantum port-show 38eea51a-2956-4168-aaeb-e52a3b5e9505 (internal interface) > +----------------------+------------------------------------------------------------------------------------+ > | Field | Value | > +----------------------+------------------------------------------------------------------------------------+ > | admin_state_up | True | > | binding:capabilities | {"port_filter": true} | > | binding:vif_type | ovs | > | device_id | 946402dd-cefc-4317-b640-a2d2f53cdd9e | > | device_owner | network:router_interface | > | fixed_ips | {"subnet_id": "182c64c0-9671-4c48-b50c-91e8bb24ccbd", "ip_address": "192.168.1.1"} | > | id | 38eea51a-2956-4168-aaeb-e52a3b5e9505 | > | mac_address | fa:16:3e:d4:77:39 | > | name | | > | network_id | 02af0ab9-6ef1-4250-be48-feb36cc98d00 | > | security_groups | | > | status | ACTIVE | > | tenant_id | 35caeda3b4d84d1582e675c2f871a00c | > +----------------------+------------------------------------------------------------------------------------+ > [root at cloud1 ~(keystone_admin)]# quantum port-show 22ed85aa-63f8-4cce-9cfb-d75409c45014 (external interface) > +----------------------+---------------------------------------------------------------------------------+ > | Field | Value | > +----------------------+---------------------------------------------------------------------------------+ > | admin_state_up | True | > | binding:capabilities | {"port_filter": true} | > | binding:vif_type | ovs | > | device_id | 946402dd-cefc-4317-b640-a2d2f53cdd9e | > | device_owner | network:router_interface | > | fixed_ips | {"subnet_id": "b41f60d2-d880-48dc-8588-60bafe712180", "ip_address": "10.2.0.1"} | > | id | 22ed85aa-63f8-4cce-9cfb-d75409c45014 | > | mac_address | fa:16:3e:20:14:44 | > | name | | > | network_id | b343ced9-89a9-43dc-bea9-861f9bf6123f | > | security_groups | | > | status | ACTIVE | > | tenant_id | 35caeda3b4d84d1582e675c2f871a00c | > +----------------------+---------------------------------------------------------------------------------+ > > When running "ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e ssh hchen at 192.168.1.102" I did not get any response. Any suggestions? > > Thanks, > Hao > > -----Original Message----- > From: Rhys Oxenham [mailto:roxenham at redhat.com] > Sent: July 30, 2013 17:40 > To: Chen, Hao > Cc: rhos-list at redhat.com > Subject: Re: [rhos-list] Validating the installation > > Hi Hao, > > On 31 Jul 2013, at 00:25, "Chen, Hao" wrote: > >> Greetings, >> >> (1) After creating an instance with rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2, a KVM Guest Image downloaded fromhttps://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952, I was asked for the Login ID and Password for the console access. Does anyone know the Login info? > > Please see: http://rhn.redhat.com/errata/RHSA-2013-0849.html (https://bugzilla.redhat.com/show_bug.cgi?id=964299) > > As far as I'm aware the image expects you to inject an SSH key using the metadata service in OpenStack and that the default root password is locked. Once connected into the instance via the SSH key it would be possible to reset the root password there. But hopefully others will clarify the situation. > > If this is not an option for you, you may want to take the image and use libguestfs/guestfish to make modifications to the image before uploading into Glance. For example, set the root password to something specific to your requirements, but please note that the image will likely disable password logins via sshd, so this too will have to be changed. > > If this is ONLY for testing and will not be used in production then I'd just reset the root password to blank as it's quick and easy to get the image up and running, below is just an example... > > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PasswordAuthentication.*/PasswordAuthentication yes/' > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PermitRootLogin.*/PermitRootLogin yes/' > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PermitEmptyPasswords.*/PermitEmptyPasswords yes/' > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^root:.*?:/root::/' > # glance image-create .... > > I've not tested the above, it may require further steps for it to work as expected. I'll try this out in the morning. > >> >> (2) I am having trouble with the Router Interfaces. The internal interface is working " 192.168.1.1 ACTIVE Internal Interface", but the status of the external interface always shows Down "10.2.0.193 DOWN External Gateway". Very grateful for any suggestions. > > I too have this, my internal interface (as in the internal port on the router) is shown as "UP" yet the external gateway port is "DOWN". I don't actually have any problems though... > > [root at openstack-controller ~(keystone_admin)]$ quantum port-show 11f2d170-baec-461f-bc30-b1f880132a03 > +----------------------+---------------------------------------------------------------------------------------+ > | Field | Value | > +----------------------+---------------------------------------------------------------------------------------+ > | admin_state_up | True | > | binding:capabilities | {"port_filter": true} | > | binding:vif_type | ovs | > | device_id | 6bea3ee4-47d6-4a3e-a9da-c82fed18baa0 | > | device_owner | network:router_gateway | > | fixed_ips | {"subnet_id": "89ee4bc1-073e-4ccd-a108-6c839dad011d", "ip_address": "192.168.122.10"} | > | id | 11f2d170-baec-461f-bc30-b1f880132a03 | > | mac_address | fa:16:3e:cd:2b:20 | > | name | | > | network_id | 7382ead9-faba-405a-a78f-404c236c9334 | > | security_groups | | > | status | DOWN | > | tenant_id | | > +----------------------+---------------------------------------------------------------------------------------+ > > Yet the L3 agent works perfectly for me... > > [root at openstack-controller ~(keystone_admin)]$ ip netns exec qrouter-6bea3ee4-47d6-4a3e-a9da-c82fed18baa0 ssh cirros at 30.0.0.4 cirros at 30.0.0.4's password: > $ ping 8.8.8.8 -c 3 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > 64 bytes from 8.8.8.8: seq=0 ttl=127 time=29.141 ms > 64 bytes from 8.8.8.8: seq=1 ttl=127 time=32.105 ms > 64 bytes from 8.8.8.8: seq=2 ttl=127 time=27.258 ms > > --- 8.8.8.8 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 27.258/29.501/32.105 ms > > Do things work for you like above, or are you seeing problems? > > > Cheers, > Rhys > > >> >> Thanks, >> Hao >> >> >> _______________________________________________ >> rhos-list mailing list >> rhos-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhos-list > > From Hao.Chen at NRCan-RNCan.gc.ca Fri Aug 2 21:32:31 2013 From: Hao.Chen at NRCan-RNCan.gc.ca (Chen, Hao) Date: Fri, 2 Aug 2013 21:32:31 +0000 Subject: [rhos-list] Validating the installation In-Reply-To: <03E7C84E-9040-4E82-B406-1BBE0BA45A07@redhat.com> References: <76CC67FD1C99DB4DB4D43FEF354AADB647015BE8@S-BSC-MBX2.nrn.nrcan.gc.ca> <471B1A3D-CD02-46DA-8E4C-5D1E0850AEA3@redhat.com> <76CC67FD1C99DB4DB4D43FEF354AADB64701652B@S-BSC-MBX2.nrn.nrcan.gc.ca> <03E7C84E-9040-4E82-B406-1BBE0BA45A07@redhat.com> Message-ID: <76CC67FD1C99DB4DB4D43FEF354AADB647016A2A@S-BSC-MBX2.nrn.nrcan.gc.ca> Hi Rhys, Thanks for your suggestions. 1) From within your instances you cannot get access the outside world, i.e. it won't go any further than 10.2.0.1 (or 192.168.1.1)? Yes. The instances can ping each other, the internal interface 192.168.1.1, and the external interface 10.2.0.195 (after resetting router gateway, now .195), but it can't go further. I realized that I have "tenant_network_type = local". Is this the problem? I tried to switch "tenant_network_type = vlan" and have "network_vlan_ranges = physnet1:70:80", but didn't know how to set up "bridge_mappings = ?". Which of the following parameters should I use? "physnet1:br-ex" "physnet1:eth0" (physical interface) "physnet1:70:80" In https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack_Preview/3/html/Installation_and_Configuration_Guide/sect-Configuring_the_Plug-in_Agent.html it says " # openstack-config --set /etc/quantum/plugin.ini OVS bridge_mappings MAPPINGS" - " Replace MAPPINGS with the physical network to VLAN range mappings." The example in /etc/quantum/plugin.ini is like "physnet1:br-eth1". 2) You cannot use the namespace to SSH into your instances via the tenant-network address, e.g. 192.168.1.102? I guess this is the same problem caused by "tenant_network_type = local"? Thanks Hao [root at cloud1 ~(keystone_admin)]# ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.0.0 * 255.255.255.0 U 0 0 0 qg-cb09493c-cb 192.168.1.0 * 255.255.255.0 U 0 0 0 qr-38eea51a-29 default 10.2.0.1 0.0.0.0 UG 0 0 0 qg-cb09493c-cb [root at cloud1 ~(keystone_admin)]# ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e ip a 37: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 40: qr-38eea51a-29: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:d4:77:39 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global qr-38eea51a-29 inet6 fe80::f816:3eff:fed4:7739/64 scope link valid_lft forever preferred_lft forever 69: qg-cb09493c-cb: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:57:23:c5 brd ff:ff:ff:ff:ff:ff inet 10.2.0.195/24 brd 10.2.0.255 scope global qg-cb09493c-cb inet6 fe80::f816:3eff:fe57:23c5/64 scope link valid_lft forever preferred_lft forever On 1 Aug 2013, at 19:50, "Chen, Hao" wrote: > Hi Rhys, > > Thanks for the suggestions. But I still could not reach the external network from the internal subnet even though the interface status became "Active". The screenshot of the network topology is attached. The internal network (192.168.1.0/24) is working well. 10.2.0.1 is the external gate way. From the internal subnet I can ping the gateway 192.168.1.1/10.2.0.1, but just cannot reach outside and the 10.2. network. > > [root at cloud1 ~(keystone_admin)]# quantum port-show > 38eea51a-2956-4168-aaeb-e52a3b5e9505 (internal interface) > +----------------------+------------------------------------------------------------------------------------+ > | Field | Value | > +----------------------+------------------------------------------------------------------------------------+ > | admin_state_up | True | > | binding:capabilities | {"port_filter": true} | > | binding:vif_type | ovs | > | device_id | 946402dd-cefc-4317-b640-a2d2f53cdd9e | > | device_owner | network:router_interface | > | fixed_ips | {"subnet_id": "182c64c0-9671-4c48-b50c-91e8bb24ccbd", "ip_address": "192.168.1.1"} | > | id | 38eea51a-2956-4168-aaeb-e52a3b5e9505 | > | mac_address | fa:16:3e:d4:77:39 | > | name | | > | network_id | 02af0ab9-6ef1-4250-be48-feb36cc98d00 | > | security_groups | | > | status | ACTIVE | > | tenant_id | 35caeda3b4d84d1582e675c2f871a00c | > +----------------------+------------------------------------------------------------------------------------+ > [root at cloud1 ~(keystone_admin)]# quantum port-show > 22ed85aa-63f8-4cce-9cfb-d75409c45014 (external interface) > +----------------------+---------------------------------------------------------------------------------+ > | Field | Value | > +----------------------+---------------------------------------------------------------------------------+ > | admin_state_up | True | > | binding:capabilities | {"port_filter": true} | > | binding:vif_type | ovs | > | device_id | 946402dd-cefc-4317-b640-a2d2f53cdd9e | > | device_owner | network:router_interface | > | fixed_ips | {"subnet_id": "b41f60d2-d880-48dc-8588-60bafe712180", "ip_address": "10.2.0.1"} | > | id | 22ed85aa-63f8-4cce-9cfb-d75409c45014 | > | mac_address | fa:16:3e:20:14:44 | > | name | | > | network_id | b343ced9-89a9-43dc-bea9-861f9bf6123f | > | security_groups | | > | status | ACTIVE | > | tenant_id | 35caeda3b4d84d1582e675c2f871a00c | > +----------------------+---------------------------------------------------------------------------------+ > > When running "ip netns exec qrouter-946402dd-cefc-4317-b640-a2d2f53cdd9e ssh hchen at 192.168.1.102" I did not get any response. Any suggestions? > > Thanks, > Hao > > -----Original Message----- > From: Rhys Oxenham [mailto:roxenham at redhat.com] > Sent: July 30, 2013 17:40 > To: Chen, Hao > Cc: rhos-list at redhat.com > Subject: Re: [rhos-list] Validating the installation > > Hi Hao, > > On 31 Jul 2013, at 00:25, "Chen, Hao" wrote: > >> Greetings, >> >> (1) After creating an instance with rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2, a KVM Guest Image downloaded fromhttps://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952, I was asked for the Login ID and Password for the console access. Does anyone know the Login info? > > Please see: http://rhn.redhat.com/errata/RHSA-2013-0849.html > (https://bugzilla.redhat.com/show_bug.cgi?id=964299) > > As far as I'm aware the image expects you to inject an SSH key using the metadata service in OpenStack and that the default root password is locked. Once connected into the instance via the SSH key it would be possible to reset the root password there. But hopefully others will clarify the situation. > > If this is not an option for you, you may want to take the image and use libguestfs/guestfish to make modifications to the image before uploading into Glance. For example, set the root password to something specific to your requirements, but please note that the image will likely disable password logins via sshd, so this too will have to be changed. > > If this is ONLY for testing and will not be used in production then I'd just reset the root password to blank as it's quick and easy to get the image up and running, below is just an example... > > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PasswordAuthentication.*/PasswordAuthentication yes/' > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PermitRootLogin.*/PermitRootLogin yes/' > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^PermitEmptyPasswords.*/PermitEmptyPasswords yes/' > # virt-edit -a /path/to/rhel-server-x86_64-kvm-6.4_20130130.0-4.qcow2 /etc/ssh/sshd_config -e 's/^root:.*?:/root::/' > # glance image-create .... > > I've not tested the above, it may require further steps for it to work as expected. I'll try this out in the morning. > >> >> (2) I am having trouble with the Router Interfaces. The internal interface is working " 192.168.1.1 ACTIVE Internal Interface", but the status of the external interface always shows Down "10.2.0.193 DOWN External Gateway". Very grateful for any suggestions. > > I too have this, my internal interface (as in the internal port on the router) is shown as "UP" yet the external gateway port is "DOWN". I don't actually have any problems though... > > [root at openstack-controller ~(keystone_admin)]$ quantum port-show > 11f2d170-baec-461f-bc30-b1f880132a03 > +----------------------+---------------------------------------------------------------------------------------+ > | Field | Value | > +----------------------+---------------------------------------------------------------------------------------+ > | admin_state_up | True | > | binding:capabilities | {"port_filter": true} | > | binding:vif_type | ovs | > | device_id | 6bea3ee4-47d6-4a3e-a9da-c82fed18baa0 | > | device_owner | network:router_gateway | > | fixed_ips | {"subnet_id": "89ee4bc1-073e-4ccd-a108-6c839dad011d", "ip_address": "192.168.122.10"} | > | id | 11f2d170-baec-461f-bc30-b1f880132a03 | > | mac_address | fa:16:3e:cd:2b:20 | > | name | | > | network_id | 7382ead9-faba-405a-a78f-404c236c9334 | > | security_groups | | > | status | DOWN | > | tenant_id | | > +----------------------+---------------------------------------------------------------------------------------+ > > Yet the L3 agent works perfectly for me... > > [root at openstack-controller ~(keystone_admin)]$ ip netns exec qrouter-6bea3ee4-47d6-4a3e-a9da-c82fed18baa0 ssh cirros at 30.0.0.4 cirros at 30.0.0.4's password: > $ ping 8.8.8.8 -c 3 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > 64 bytes from 8.8.8.8: seq=0 ttl=127 time=29.141 ms > 64 bytes from 8.8.8.8: seq=1 ttl=127 time=32.105 ms > 64 bytes from 8.8.8.8: seq=2 ttl=127 time=27.258 ms > > --- 8.8.8.8 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss round-trip > min/avg/max = 27.258/29.501/32.105 ms > > Do things work for you like above, or are you seeing problems? > > > Cheers, > Rhys > > >> >> Thanks, >> Hao >> >> >> _______________________________________________ >> rhos-list mailing list >> rhos-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhos-list > > From haliu at redhat.com Mon Aug 5 16:11:01 2013 From: haliu at redhat.com (Hangbin Liu) Date: Tue, 6 Aug 2013 00:11:01 +0800 Subject: [rhos-list] How to config quantum external network? Message-ID: <20130805161101.GZ14331@localhost.localdomain> Hi all, I usually use packstack to set up openstack environment with to compute nodes. But I only know how to add one internal vlan network with openvwitch. Could you tell me how to config the external network? My testing machines are in beaker, and the testing topo is like: |-- (eth0) Host A (eth1) --| beaker_switch --| |-- our_own_switch (external net) |-- (eth0) Host B (eth1) --| (internal net) Here is my packstack quantum config: CONFIG_QUANTUM_SERVER_HOST=10.66.86.101 CONFIG_QUANTUM_USE_NAMESPACES=y CONFIG_QUANTUM_KS_PW=redhat CONFIG_QUANTUM_DB_PW=redhat CONFIG_QUANTUM_L3_HOSTS=10.66.86.101 CONFIG_QUANTUM_L3_EXT_BRIDGE=br-ex CONFIG_QUANTUM_DHCP_HOSTS=10.66.86.101 CONFIG_QUANTUM_L2_PLUGIN=openvswitch CONFIG_QUANTUM_METADATA_HOSTS=10.66.86.101 CONFIG_QUANTUM_METADATA_PW=redhat CONFIG_QUANTUM_LB_TENANT_NETWORK_TYPE=local CONFIG_QUANTUM_OVS_TENANT_NETWORK_TYPE=vlan CONFIG_QUANTUM_OVS_VLAN_RANGES=physnet1:10:100 CONFIG_QUANTUM_OVS_BRIDGE_MAPPINGS=physnet1:br-link1 CONFIG_QUANTUM_OVS_BRIDGE_IFACES=br-link1:eth1 After install finished on Host A and Host B, I got topo like: -- br-link1 -- -- br-int -- | | | | eth1 phy-br-link1 <--> int-br-link1 vm-tap-device Here my VMs can connect each other from br-link1 via eth1. But I don't know how to conected the VMs through beaker. some internal subnet info listed. On compute node 1: # quantum agent-list +--------------------------------------+--------------------+----------------------------------------+-------+----------------+ | id | agent_type | host | alive | admin_state_up | +--------------------------------------+--------------------+----------------------------------------+-------+----------------+ | 1f7e0753-73f6-458d-b0c7-1fb7de3a507c | DHCP agent | ibm-x3550m3-04.rhts.eng.nay.redhat.com | :-) | True | | 8ace71a9-a377-4cc4-a4ad-d6964ef08ffa | Open vSwitch agent | ibm-x3650-02.rhts.eng.nay.redhat.com | :-) | True | | e71c227b-e665-48b8-b97e-152df5f34269 | L3 agent | ibm-x3550m3-04.rhts.eng.nay.redhat.com | :-) | True | | fd09eabe-0d6e-47ae-b0ea-75268840493e | Open vSwitch agent | ibm-x3550m3-04.rhts.eng.nay.redhat.com | :-) | True | +--------------------------------------+--------------------+----------------------------------------+-------+----------------+ # quantum net-list +--------------------------------------+--------------+------------------------------------------------------+ | id | name | subnets | +--------------------------------------+--------------+------------------------------------------------------+ | 34e2c2f4-7161-4c0c-a306-40dc8dce1086 | Vlan_Network | 01652f1c-578a-4058-a673-1d2d2194e707 192.168.10.0/24 | | b9d2d4fc-98a6-464e-b3d7-c5e2a6598d09 | public | | +--------------------------------------+--------------+------------------------------------------------------+ # quantum subnet-list +--------------------------------------+------+-----------------+----------------------------------------------------+ | id | name | cidr | allocation_pools | +--------------------------------------+------+-----------------+----------------------------------------------------+ | 01652f1c-578a-4058-a673-1d2d2194e707 | | 192.168.10.0/24 | {"start": "192.168.10.2", "end": "192.168.10.253"} | +--------------------------------------+------+-----------------+----------------------------------------------------+ # quantum net-show 34e2c2f4-7161-4c0c-a306-40dc8dce1086 +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | 34e2c2f4-7161-4c0c-a306-40dc8dce1086 | | name | Vlan_Network | | provider:network_type | vlan | | provider:physical_network | physnet1 | | provider:segmentation_id | 10 | | router:external | True | | shared | False | | status | ACTIVE | | subnets | 01652f1c-578a-4058-a673-1d2d2194e707 | | tenant_id | ea0c68c1d83743a5a19a3f33f434485a | +---------------------------+--------------------------------------+ # quantum subnet-show 01652f1c-578a-4058-a673-1d2d2194e707 +------------------+----------------------------------------------------+ | Field | Value | +------------------+----------------------------------------------------+ | allocation_pools | {"start": "192.168.10.2", "end": "192.168.10.253"} | | cidr | 192.168.10.0/24 | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 192.168.10.254 | | host_routes | | | id | 01652f1c-578a-4058-a673-1d2d2194e707 | | ip_version | 4 | | name | | | network_id | 34e2c2f4-7161-4c0c-a306-40dc8dce1086 | | tenant_id | ea0c68c1d83743a5a19a3f33f434485a | +------------------+----------------------------------------------------+ # ovs-vsctl show a8f0551a-8197-47e9-bdd5-db7b0ef9394d Bridge br-int Port "qvo7858e34e-20" tag: 1 Interface "qvo7858e34e-20" Port "int-br-link1" Interface "int-br-link1" Port "tap138e4dd7-72" tag: 1 Interface "tap138e4dd7-72" Port br-int Interface br-int type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Bridge "br-link1" Port "br-link1" Interface "br-link1" type: internal Port "eth1" Interface "eth1" Port "phy-br-link1" Interface "phy-br-link1" ovs_version: "1.9.0" On compute node 2: # ovs-vsctl show 02249bbc-a5c6-4343-906a-7949ae821b91 Bridge br-int Port br-int Interface br-int type: internal Port "qvoc9c8e777-38" tag: 1 Interface "qvoc9c8e777-38" Port "int-br-link1" Interface "int-br-link1" Bridge "br-link1" Port "br-link1" Interface "br-link1" type: internal Port "eth1" Interface "eth1" Port "phy-br-link1" Interface "phy-br-link1" ovs_version: "1.9.0" -- Thanks & Best Regards Hangbin Liu Leo on #kernel-qe, #kernel, #eng-china From mehbhatt at cisco.com Tue Aug 6 07:03:22 2013 From: mehbhatt at cisco.com (Mehul Bhatt (mehbhatt)) Date: Tue, 6 Aug 2013 07:03:22 +0000 Subject: [rhos-list] subscription manager / yum working on one system but not the other Message-ID: Hi guys, I have to identical systems where I installed RHEL 6.2 and upgraded to 6.4. Both are registered w/ subscription-manager. The series of command I'm running are as follows: subscription-manager register subscription-manager list --available subscription-manager attach --pool=POOLID yum repolist yum install -y yum-utils Both systems are able to attach to a given pool, but one is actually able to download the packages using yum and install them - the other one can't. Good system: [root at rhos-node2 ~]# yum install -y yum-utils Loaded plugins: priorities, product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rpms | 3.7 kB 00:00 rhel-server-ost-6-3-rpms | 2.8 kB 00:00 322 packages excluded due to repository priority protections Setting up Install Process Package yum-utils-1.1.30-14.el6.noarch already installed and latest version Nothing to do Bad system: [root at rhos-node1 ~]# yum install -y yum-utils Loaded plugins: product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. Setting up Install Process Nothing to do Basically, the bad system doesn't seem to connecting and checking the available packages / dependancies. Any clue where should I be looking / fixing? Thanks, -Mehul. From bkearney at redhat.com Tue Aug 6 12:40:42 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 06 Aug 2013 08:40:42 -0400 Subject: [rhos-list] subscription manager / yum working on one system but not the other In-Reply-To: References: Message-ID: <5200EECA.9010106@redhat.com> On 08/06/2013 03:03 AM, Mehul Bhatt (mehbhatt) wrote: > Hi guys, > > I have to identical systems where I installed RHEL 6.2 and upgraded to 6.4. Both are registered w/ subscription-manager. The series of command I'm running are as follows: > > subscription-manager register > > subscription-manager list --available > > subscription-manager attach --pool=POOLID > > yum repolist > > yum install -y yum-utils > > > Both systems are able to attach to a given pool, but one is actually able to download the packages using yum and install them - the other one can't. > > Good system: > > [root at rhos-node2 ~]# yum install -y yum-utils > Loaded plugins: priorities, product-id, security, subscription-manager > This system is receiving updates from Red Hat Subscription Management. > rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 > rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 > rhel-6-server-rpms | 3.7 kB 00:00 > rhel-server-ost-6-3-rpms | 2.8 kB 00:00 > 322 packages excluded due to repository priority protections > Setting up Install Process > Package yum-utils-1.1.30-14.el6.noarch already installed and latest version > Nothing to do > > Bad system: > > [root at rhos-node1 ~]# yum install -y yum-utils > Loaded plugins: product-id, security, subscription-manager > This system is receiving updates from Red Hat Subscription Management. > Setting up Install Process > Nothing to do > > > Basically, the bad system doesn't seem to connecting and checking the available packages / dependancies. > > Any clue where should I be looking / fixing? What does subscription-manager list --installed show you on each machine? I am guesisng the bad machine has no product id on it. -- bk From mehbhatt at cisco.com Tue Aug 6 16:20:29 2013 From: mehbhatt at cisco.com (Mehul Bhatt (mehbhatt)) Date: Tue, 6 Aug 2013 16:20:29 +0000 Subject: [rhos-list] subscription manager / yum working on one system but not the other In-Reply-To: <5200EECA.9010106@redhat.com> References: <5200EECA.9010106@redhat.com> Message-ID: Doesn't look anything different - other than the fact that the bad one doesn't have RHOS still installed. I also increased yum debug level and see the difference between yum logs on two machines - nothing specific catches my eyes. vi /etc/yum.conf [main] cachedir=/var/cache/yum/$basearch/$releasever keepcache=0 debuglevel=5 <<-- changed this Logs has this: This system is receiving updates from Red Hat Subscription Management. Config time: 2.269 Yum Version: 3.2.29 COMMAND: yum install -y yum-utils Installroot: / Ext Commands: yum-utils Setting up Package Sacks Reading Local RPMDB rpmdb time: 0.000 Setting up Install Process Setting up Package Sacks Checking for virtual provide or file-provide for yum-utils Setting up Package Sacks Nothing to do And BTW, here's the difference between "subscription-manager list --installed" : On good one: [root at rhos-node2 ~]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 6.3 Arch: x86_64 Status: Subscribed Starts: 07/23/2013 Ends: 09/21/2013 Product Name: Red Hat OpenStack Product ID: 191 Version: 3.0 Arch: x86_64 Status: Subscribed Starts: 07/23/2013 Ends: 09/21/2013 On bad one: [root at rhos-node1 ~]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 6.4 Beta Arch: x86_64 Status: Subscribed Starts: 07/23/2013 Ends: 09/21/2013 [root at rhos-node1 ~]# -Mehul. -----Original Message----- From: rhos-list-bounces at redhat.com [mailto:rhos-list-bounces at redhat.com] On Behalf Of Bryan Kearney Sent: Tuesday, August 06, 2013 6:11 PM To: rhos-list at redhat.com Subject: Re: [rhos-list] subscription manager / yum working on one system but not the other On 08/06/2013 03:03 AM, Mehul Bhatt (mehbhatt) wrote: > Hi guys, > > I have to identical systems where I installed RHEL 6.2 and upgraded to 6.4. Both are registered w/ subscription-manager. The series of command I'm running are as follows: > > subscription-manager register > > subscription-manager list --available > > subscription-manager attach --pool=POOLID > > yum repolist > > yum install -y yum-utils > > > Both systems are able to attach to a given pool, but one is actually able to download the packages using yum and install them - the other one can't. > > Good system: > > [root at rhos-node2 ~]# yum install -y yum-utils Loaded plugins: > priorities, product-id, security, subscription-manager This system is > receiving updates from Red Hat Subscription Management. > rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 > rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 > rhel-6-server-rpms | 3.7 kB 00:00 > rhel-server-ost-6-3-rpms | 2.8 kB 00:00 > 322 packages excluded due to repository priority protections Setting > up Install Process Package yum-utils-1.1.30-14.el6.noarch already > installed and latest version Nothing to do > > Bad system: > > [root at rhos-node1 ~]# yum install -y yum-utils Loaded plugins: > product-id, security, subscription-manager This system is receiving > updates from Red Hat Subscription Management. > Setting up Install Process > Nothing to do > > > Basically, the bad system doesn't seem to connecting and checking the available packages / dependancies. > > Any clue where should I be looking / fixing? What does subscription-manager list --installed show you on each machine? I am guesisng the bad machine has no product id on it. -- bk _______________________________________________ rhos-list mailing list rhos-list at redhat.com https://www.redhat.com/mailman/listinfo/rhos-list From bkearney at redhat.com Tue Aug 6 16:22:53 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 06 Aug 2013 12:22:53 -0400 Subject: [rhos-list] subscription manager / yum working on one system but not the other In-Reply-To: References: <5200EECA.9010106@redhat.com> Message-ID: <520122DD.4040009@redhat.com> On 08/06/2013 12:20 PM, Mehul Bhatt (mehbhatt) wrote: > Doesn't look anything different - other than the fact that the bad one doesn't have RHOS still installed. I also increased yum debug level and see the difference between yum logs on two machines - nothing specific catches my eyes. > > vi /etc/yum.conf > > [main] > cachedir=/var/cache/yum/$basearch/$releasever > keepcache=0 > debuglevel=5 <<-- changed this > > Logs has this: > This system is receiving updates from Red Hat Subscription Management. > Config time: 2.269 > Yum Version: 3.2.29 > COMMAND: yum install -y yum-utils > Installroot: / > Ext Commands: > > yum-utils > Setting up Package Sacks > Reading Local RPMDB > rpmdb time: 0.000 > Setting up Install Process > Setting up Package Sacks > Checking for virtual provide or file-provide for yum-utils > Setting up Package Sacks > Nothing to do > > > > And BTW, here's the difference between "subscription-manager list --installed" : > > > > On good one: > > [root at rhos-node2 ~]# subscription-manager list --installed > +-------------------------------------------+ > Installed Product Status > +-------------------------------------------+ > Product Name: Red Hat Enterprise Linux Server > Product ID: 69 > Version: 6.3 > Arch: x86_64 > Status: Subscribed > Starts: 07/23/2013 > Ends: 09/21/2013 > > Product Name: Red Hat OpenStack > Product ID: 191 > Version: 3.0 > Arch: x86_64 > Status: Subscribed > Starts: 07/23/2013 > Ends: 09/21/2013 > > > On bad one: > > [root at rhos-node1 ~]# subscription-manager list --installed > +-------------------------------------------+ > Installed Product Status > +-------------------------------------------+ > Product Name: Red Hat Enterprise Linux Server > Product ID: 69 > Version: 6.4 Beta > Arch: x86_64 > Status: Subscribed > Starts: 07/23/2013 > Ends: 09/21/2013 > > [root at rhos-node1 ~]# > > I wonder if beta is the issue? That may lock you out of prod bits. Are there any enabled repos (subscription-manager repos --list) -- bk From red at fedoraproject.org Sun Aug 11 20:58:39 2013 From: red at fedoraproject.org (Sandro "red" Mathys) Date: Sun, 11 Aug 2013 22:58:39 +0200 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <512FC464.1060107@redhat.com> References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> Message-ID: FYI, I went ahead and proposed a change to implement this: https://review.openstack.org/#/c/41319/ Note, that I only just had the time to test it on F19. -- Sandro On Thu, Feb 28, 2013 at 9:56 PM, Derek Higgins wrote: > On 02/28/2013 07:58 PM, Perry Myers wrote: > > On 02/28/2013 02:25 PM, Daniel P. Berrange wrote: > >> On Thu, Feb 28, 2013 at 07:12:38PM +0000, Minton, Rich wrote: > >>> Is the virbr0 interface required and if not how do I get rid of it? It > seems to spin up another dnsmasq process that interferes with VlanManger > networks. > >> > >> Just do > >> > >> virsh net-destroy default > >> virsh net-autostart --disable default > > > > Derek/Martin, does it make sense to do this as part of packstack > > installation? If so a bug for this would be useful in bugzilla > > Its certainly something we could add but I havn't ever seen virbr0 cause > problems the the networking that packstack sets up. Wouldn't be any harm > to remove it anyways to avoid confusion. > > > > > Perry > > > > _______________________________________________ > rhos-list mailing list > rhos-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhos-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkarani1 at in.ibm.com Mon Aug 12 16:37:27 2013 From: vkarani1 at in.ibm.com (Velayutham Karani1) Date: Mon, 12 Aug 2013 22:07:27 +0530 Subject: [rhos-list] AUTO: Velayutham Karani1 is out of the office (returning 13-08-2013) Message-ID: I am out of the office until 13-08-2013. I am out of office, with no access to email and limited access to mobile. I can reply to your mail on my return and respond to sms as and when possible. Thanks, Velu. Note: This is an automated response to your message "rhos-list Digest, Vol 13, Issue 7" sent on 12/08/2013 21:30:04. This is the only notification you will receive while this person is away. From dallan at redhat.com Mon Aug 12 20:24:55 2013 From: dallan at redhat.com (Dave Allan) Date: Mon, 12 Aug 2013 16:24:55 -0400 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> Message-ID: <20130812202455.GH2107@redhat.com> Note that on recent Fedora the default network is a separate package libvirt-daemon-config-network which should simply not be installed if the default network is not desirable. Dave On Sun, Aug 11, 2013 at 10:58:39PM +0200, Sandro "red" Mathys wrote: > FYI, I went ahead and proposed a change to implement this: > https://review.openstack.org/#/c/41319/ > > Note, that I only just had the time to test it on F19. > > -- Sandro > > > On Thu, Feb 28, 2013 at 9:56 PM, Derek Higgins wrote: > > > On 02/28/2013 07:58 PM, Perry Myers wrote: > > > On 02/28/2013 02:25 PM, Daniel P. Berrange wrote: > > >> On Thu, Feb 28, 2013 at 07:12:38PM +0000, Minton, Rich wrote: > > >>> Is the virbr0 interface required and if not how do I get rid of it? It > > seems to spin up another dnsmasq process that interferes with VlanManger > > networks. > > >> > > >> Just do > > >> > > >> virsh net-destroy default > > >> virsh net-autostart --disable default > > > > > > Derek/Martin, does it make sense to do this as part of packstack > > > installation? If so a bug for this would be useful in bugzilla > > > > Its certainly something we could add but I havn't ever seen virbr0 cause > > problems the the networking that packstack sets up. Wouldn't be any harm > > to remove it anyways to avoid confusion. > > > > > > > > Perry > > > > > > > _______________________________________________ > > rhos-list mailing list > > rhos-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rhos-list > > > _______________________________________________ > rhos-list mailing list > rhos-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhos-list From red at fedoraproject.org Tue Aug 13 00:00:32 2013 From: red at fedoraproject.org (Sandro "red" Mathys) Date: Tue, 13 Aug 2013 02:00:32 +0200 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <20130812202455.GH2107@redhat.com> References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> Message-ID: On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan wrote: > Note that on recent Fedora the default network is a separate package > libvirt-daemon-config-network which should simply not be installed if > the default network is not desirable. > Interesting. So the upstream Nova Puppet module simply installs libvirt and openstack-nova-compute. Does that mean libvirt-daemon-config-network will not be installed? Or is libvirt now a metapackage that draws it all in? And if so, what package(s) should be installed instead? Thanks, Sandro > Dave > > On Sun, Aug 11, 2013 at 10:58:39PM +0200, Sandro "red" Mathys wrote: > > FYI, I went ahead and proposed a change to implement this: > > https://review.openstack.org/#/c/41319/ > > > > Note, that I only just had the time to test it on F19. > > > > -- Sandro > > > > > > On Thu, Feb 28, 2013 at 9:56 PM, Derek Higgins > wrote: > > > > > On 02/28/2013 07:58 PM, Perry Myers wrote: > > > > On 02/28/2013 02:25 PM, Daniel P. Berrange wrote: > > > >> On Thu, Feb 28, 2013 at 07:12:38PM +0000, Minton, Rich wrote: > > > >>> Is the virbr0 interface required and if not how do I get rid of > it? It > > > seems to spin up another dnsmasq process that interferes with > VlanManger > > > networks. > > > >> > > > >> Just do > > > >> > > > >> virsh net-destroy default > > > >> virsh net-autostart --disable default > > > > > > > > Derek/Martin, does it make sense to do this as part of packstack > > > > installation? If so a bug for this would be useful in bugzilla > > > > > > Its certainly something we could add but I havn't ever seen virbr0 > cause > > > problems the the networking that packstack sets up. Wouldn't be any > harm > > > to remove it anyways to avoid confusion. > > > > > > > > > > > Perry > > > > > > > > > > _______________________________________________ > > > rhos-list mailing list > > > rhos-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > > > _______________________________________________ > > rhos-list mailing list > > rhos-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rhos-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dallan at redhat.com Tue Aug 13 00:32:24 2013 From: dallan at redhat.com (Dave Allan) Date: Mon, 12 Aug 2013 20:32:24 -0400 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> Message-ID: <20130813003224.GA2124@redhat.com> On Tue, Aug 13, 2013 at 02:00:32AM +0200, Sandro "red" Mathys wrote: > On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan wrote: > > > Note that on recent Fedora the default network is a separate package > > libvirt-daemon-config-network which should simply not be installed if > > the default network is not desirable. > > > > Interesting. So the upstream Nova Puppet module simply installs libvirt and > openstack-nova-compute. Does that mean libvirt-daemon-config-network will > not be installed? Or is libvirt now a metapackage that draws it all in? And > if so, what package(s) should be installed instead? Yes, libvirt is now a metapackage. Double check me on this, but I think we just want libvirt-daemon-driver-qemu which pulls in only: libvirt-client libvirt-daemon libvirt-daemon-driver-network Dave > Thanks, > Sandro > > > > Dave > > > > On Sun, Aug 11, 2013 at 10:58:39PM +0200, Sandro "red" Mathys wrote: > > > FYI, I went ahead and proposed a change to implement this: > > > https://review.openstack.org/#/c/41319/ > > > > > > Note, that I only just had the time to test it on F19. > > > > > > -- Sandro > > > > > > > > > On Thu, Feb 28, 2013 at 9:56 PM, Derek Higgins > > wrote: > > > > > > > On 02/28/2013 07:58 PM, Perry Myers wrote: > > > > > On 02/28/2013 02:25 PM, Daniel P. Berrange wrote: > > > > >> On Thu, Feb 28, 2013 at 07:12:38PM +0000, Minton, Rich wrote: > > > > >>> Is the virbr0 interface required and if not how do I get rid of > > it? It > > > > seems to spin up another dnsmasq process that interferes with > > VlanManger > > > > networks. > > > > >> > > > > >> Just do > > > > >> > > > > >> virsh net-destroy default > > > > >> virsh net-autostart --disable default > > > > > > > > > > Derek/Martin, does it make sense to do this as part of packstack > > > > > installation? If so a bug for this would be useful in bugzilla > > > > > > > > Its certainly something we could add but I havn't ever seen virbr0 > > cause > > > > problems the the networking that packstack sets up. Wouldn't be any > > harm > > > > to remove it anyways to avoid confusion. > > > > > > > > > > > > > > Perry > > > > > > > > > > > > > _______________________________________________ > > > > rhos-list mailing list > > > > rhos-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > > > > > > _______________________________________________ > > > rhos-list mailing list > > > rhos-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > From red at fedoraproject.org Tue Aug 13 02:45:28 2013 From: red at fedoraproject.org (Sandro "red" Mathys) Date: Tue, 13 Aug 2013 04:45:28 +0200 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <20130813003224.GA2124@redhat.com> References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> <20130813003224.GA2124@redhat.com> Message-ID: On Tue, Aug 13, 2013 at 2:32 AM, Dave Allan wrote: > On Tue, Aug 13, 2013 at 02:00:32AM +0200, Sandro "red" Mathys wrote: > > On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan wrote: > > > > > Note that on recent Fedora the default network is a separate package > > > libvirt-daemon-config-network which should simply not be installed if > > > the default network is not desirable. > > > > > > > Interesting. So the upstream Nova Puppet module simply installs libvirt > and > > openstack-nova-compute. Does that mean libvirt-daemon-config-network will > > not be installed? Or is libvirt now a metapackage that draws it all in? > And > > if so, what package(s) should be installed instead? > > Yes, libvirt is now a metapackage. > > Double check me on this, but I think we just want > libvirt-daemon-driver-qemu which pulls in only: > > libvirt-client > libvirt-daemon > libvirt-daemon-driver-network > Will give that a try when I find the time. So that will be Fedora >= 20 (i.e. current Rawhide and later), right? And I figure in RHEL 7, too? Just so I can cover both in one patch while at it. -- Sandro > > Thanks, > > Sandro > > > > > > > Dave > > > > > > On Sun, Aug 11, 2013 at 10:58:39PM +0200, Sandro "red" Mathys wrote: > > > > FYI, I went ahead and proposed a change to implement this: > > > > https://review.openstack.org/#/c/41319/ > > > > > > > > Note, that I only just had the time to test it on F19. > > > > > > > > -- Sandro > > > > > > > > > > > > On Thu, Feb 28, 2013 at 9:56 PM, Derek Higgins > > > wrote: > > > > > > > > > On 02/28/2013 07:58 PM, Perry Myers wrote: > > > > > > On 02/28/2013 02:25 PM, Daniel P. Berrange wrote: > > > > > >> On Thu, Feb 28, 2013 at 07:12:38PM +0000, Minton, Rich wrote: > > > > > >>> Is the virbr0 interface required and if not how do I get rid of > > > it? It > > > > > seems to spin up another dnsmasq process that interferes with > > > VlanManger > > > > > networks. > > > > > >> > > > > > >> Just do > > > > > >> > > > > > >> virsh net-destroy default > > > > > >> virsh net-autostart --disable default > > > > > > > > > > > > Derek/Martin, does it make sense to do this as part of packstack > > > > > > installation? If so a bug for this would be useful in bugzilla > > > > > > > > > > Its certainly something we could add but I havn't ever seen virbr0 > > > cause > > > > > problems the the networking that packstack sets up. Wouldn't be any > > > harm > > > > > to remove it anyways to avoid confusion. > > > > > > > > > > > > > > > > > Perry > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rhos-list mailing list > > > > > rhos-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > > > > > > > > > _______________________________________________ > > > > rhos-list mailing list > > > > rhos-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dallan at redhat.com Tue Aug 13 02:52:53 2013 From: dallan at redhat.com (Dave Allan) Date: Mon, 12 Aug 2013 22:52:53 -0400 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> <20130813003224.GA2124@redhat.com> Message-ID: <20130813025253.GB2124@redhat.com> On Tue, Aug 13, 2013 at 04:45:28AM +0200, Sandro "red" Mathys wrote: > On Tue, Aug 13, 2013 at 2:32 AM, Dave Allan wrote: > > > On Tue, Aug 13, 2013 at 02:00:32AM +0200, Sandro "red" Mathys wrote: > > > On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan wrote: > > > > > > > Note that on recent Fedora the default network is a separate package > > > > libvirt-daemon-config-network which should simply not be installed if > > > > the default network is not desirable. > > > > > > > > > > Interesting. So the upstream Nova Puppet module simply installs libvirt > > and > > > openstack-nova-compute. Does that mean libvirt-daemon-config-network will > > > not be installed? Or is libvirt now a metapackage that draws it all in? > > And > > > if so, what package(s) should be installed instead? > > > > Yes, libvirt is now a metapackage. > > > > Double check me on this, but I think we just want > > libvirt-daemon-driver-qemu which pulls in only: > > > > libvirt-client > > libvirt-daemon > > libvirt-daemon-driver-network > > > > Will give that a try when I find the time. So that will be Fedora >= 20 > (i.e. current Rawhide and later), right? And I figure in RHEL 7, too? Just > so I can cover both in one patch while at it. It's definitely in F19 and RHEL7; I'm not sure about F18, but it was broken out a while back, I just don't remember the exact date. Dave > -- Sandro > > > > > Thanks, > > > Sandro > > > > > > > > > > Dave > > > > > > > > On Sun, Aug 11, 2013 at 10:58:39PM +0200, Sandro "red" Mathys wrote: > > > > > FYI, I went ahead and proposed a change to implement this: > > > > > https://review.openstack.org/#/c/41319/ > > > > > > > > > > Note, that I only just had the time to test it on F19. > > > > > > > > > > -- Sandro > > > > > > > > > > > > > > > On Thu, Feb 28, 2013 at 9:56 PM, Derek Higgins > > > > wrote: > > > > > > > > > > > On 02/28/2013 07:58 PM, Perry Myers wrote: > > > > > > > On 02/28/2013 02:25 PM, Daniel P. Berrange wrote: > > > > > > >> On Thu, Feb 28, 2013 at 07:12:38PM +0000, Minton, Rich wrote: > > > > > > >>> Is the virbr0 interface required and if not how do I get rid of > > > > it? It > > > > > > seems to spin up another dnsmasq process that interferes with > > > > VlanManger > > > > > > networks. > > > > > > >> > > > > > > >> Just do > > > > > > >> > > > > > > >> virsh net-destroy default > > > > > > >> virsh net-autostart --disable default > > > > > > > > > > > > > > Derek/Martin, does it make sense to do this as part of packstack > > > > > > > installation? If so a bug for this would be useful in bugzilla > > > > > > > > > > > > Its certainly something we could add but I havn't ever seen virbr0 > > > > cause > > > > > > problems the the networking that packstack sets up. Wouldn't be any > > > > harm > > > > > > to remove it anyways to avoid confusion. > > > > > > > > > > > > > > > > > > > > Perry > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rhos-list mailing list > > > > > > rhos-list at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > > > > > > > > > > > > _______________________________________________ > > > > > rhos-list mailing list > > > > > rhos-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/rhos-list > > > > > > > > > > From berrange at redhat.com Tue Aug 13 08:33:14 2013 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 13 Aug 2013 09:33:14 +0100 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <20130813003224.GA2124@redhat.com> References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> <20130813003224.GA2124@redhat.com> Message-ID: <20130813083314.GA4432@redhat.com> On Mon, Aug 12, 2013 at 08:32:24PM -0400, Dave Allan wrote: > On Tue, Aug 13, 2013 at 02:00:32AM +0200, Sandro "red" Mathys wrote: > > On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan wrote: > > > > > Note that on recent Fedora the default network is a separate package > > > libvirt-daemon-config-network which should simply not be installed if > > > the default network is not desirable. > > > > > > > Interesting. So the upstream Nova Puppet module simply installs libvirt and > > openstack-nova-compute. Does that mean libvirt-daemon-config-network will > > not be installed? Or is libvirt now a metapackage that draws it all in? And > > if so, what package(s) should be installed instead? > > Yes, libvirt is now a metapackage. > > Double check me on this, but I think we just want > libvirt-daemon-driver-qemu which pulls in only: Actally you'd be better off using libvirt-daemon-kvm - this pulls in all the libvirt-daemon-driver-* that are required, along with the suitable qemu-kvm RPM, still avoiding the default configs. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From berrange at redhat.com Tue Aug 13 08:34:35 2013 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 13 Aug 2013 09:34:35 +0100 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <20130813025253.GB2124@redhat.com> References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> <20130813003224.GA2124@redhat.com> <20130813025253.GB2124@redhat.com> Message-ID: <20130813083435.GB4432@redhat.com> On Mon, Aug 12, 2013 at 10:52:53PM -0400, Dave Allan wrote: > On Tue, Aug 13, 2013 at 04:45:28AM +0200, Sandro "red" Mathys wrote: > > On Tue, Aug 13, 2013 at 2:32 AM, Dave Allan wrote: > > > > > On Tue, Aug 13, 2013 at 02:00:32AM +0200, Sandro "red" Mathys wrote: > > > > On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan wrote: > > > > > > > > > Note that on recent Fedora the default network is a separate package > > > > > libvirt-daemon-config-network which should simply not be installed if > > > > > the default network is not desirable. > > > > > > > > > > > > > Interesting. So the upstream Nova Puppet module simply installs libvirt > > > and > > > > openstack-nova-compute. Does that mean libvirt-daemon-config-network will > > > > not be installed? Or is libvirt now a metapackage that draws it all in? > > > And > > > > if so, what package(s) should be installed instead? > > > > > > Yes, libvirt is now a metapackage. > > > > > > Double check me on this, but I think we just want > > > libvirt-daemon-driver-qemu which pulls in only: > > > > > > libvirt-client > > > libvirt-daemon > > > libvirt-daemon-driver-network > > > > > > > Will give that a try when I find the time. So that will be Fedora >= 20 > > (i.e. current Rawhide and later), right? And I figure in RHEL 7, too? Just > > so I can cover both in one patch while at it. > > It's definitely in F19 and RHEL7; I'm not sure about F18, but it was > broken out a while back, I just don't remember the exact date. F18 is when it was introduced Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From prmarino1 at gmail.com Tue Aug 13 12:46:36 2013 From: prmarino1 at gmail.com (Paul Robert Marino) Date: Tue, 13 Aug 2013 08:46:36 -0400 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <20130813083314.GA4432@redhat.com> Message-ID: <520a2aad.e9a5ec0a.0858.fffff22c@mx.google.com> An HTML attachment was scrubbed... URL: From prmarino1 at gmail.com Tue Aug 13 13:27:24 2013 From: prmarino1 at gmail.com (Paul Robert Marino) Date: Tue, 13 Aug 2013 09:27:24 -0400 Subject: [rhos-list] I found a documentation bug Message-ID: this one is minor but on page https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack_Preview/3/html/Installation_and_Configuration_Guide/sect-Configuring_the_Dashboard.html it says /ect/openstack-dashboard/local_settings instead of /etc/openstack-dashboard/local_settings From sgordon at redhat.com Tue Aug 13 13:35:37 2013 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 13 Aug 2013 09:35:37 -0400 (EDT) Subject: [rhos-list] I found a documentation bug In-Reply-To: References: Message-ID: <1254217070.1270963.1376400937658.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Paul Robert Marino" > To: rhos-list at redhat.com > Sent: Tuesday, August 13, 2013 9:27:24 AM > Subject: [rhos-list] I found a documentation bug > > this one is minor but on page > https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack_Preview/3/html/Installation_and_Configuration_Guide/sect-Configuring_the_Dashboard.html > > it says /ect/openstack-dashboard/local_settings instead of > /etc/openstack-dashboard/local_settings Thanks for the report, I've fixed it in source and it will appear on the live site the next time we push an update. -- Steve Gordon, RHCE Documentation Lead, Red Hat OpenStack Engineering Content Services Red Hat Canada (Toronto, Ontario) From draddatz at sgi.com Tue Aug 13 15:02:18 2013 From: draddatz at sgi.com (David Raddatz) Date: Tue, 13 Aug 2013 15:02:18 +0000 Subject: [rhos-list] error during install using packstack Message-ID: <18CF1869BE7AB04DB1E4CC93FD43702A1B710225@P-EXMB2-DC21.corp.sgi.com> Hello, First time installation using packstack and answer file on RHEL 6.4 with RHOS 3. I received the following error: ERROR : Error during puppet run : err: /Stage[main]//Package[openstack-selinux]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-selinux' returned 1: Error: Package: openstack-selinux-0.1.2-10.el6ost.noarch (rhos3) Looking in the openstack-setup.log, here are more details: 2013-08-13 07:44:32::ERROR::ospluginutils::143::root:: Error during remote puppet apply of /var/tmp/packstack/20130813-074404-ZLEBvE/manifests/150.166.51.160_prescript.pp 2013-08-13 07:44:32::ERROR::ospluginutils::144::root:: ^[[1;35merr: /Stage[main]//Package[openstack-selinux]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-selinux' returned 1: Error: Package: openstack-selinux-0.1.2-10.el6ost.noarch (rhos3) Requires: selinux-policy-targeted >= 3.7.19-195.el6_4.2 Installed: selinux-policy-targeted-3.7.19-195.el6.noarch (@rh6.4) selinux-policy-targeted = 3.7.19-195.el6 Error: Package: openstack-selinux-0.1.2-10.el6ost.noarch (rhos3) Requires: selinux-policy-base >= 3.7.19-195.el6_4.2 Installed: selinux-policy-targeted-3.7.19-195.el6.noarch (@rh6.4) selinux-policy-base = 3.7.19-195.el6 Available: selinux-policy-minimum-3.7.19-195.el6.noarch (rh6.4) selinux-policy-base = 3.7.19-195.el6 Available: selinux-policy-mls-3.7.19-195.el6.noarch (rh6.4) selinux-policy-base = 3.7.19-195.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ^[[0m ^[[0;36mnotice: /Stage[main]/Packstack::Netns/Exec[netns_dependecy_install]/returns: executed successfully^[[0m ^[[0;36mnotice: Kernel package with netns support has been installed on host 150.166.51.160. Because of the kernel update host mentioned above requires reboot.^[[0m ^[[0;36mnotice: /Stage[main]/Packstack::Netns/Notify[packstack_info]/message: defined 'message' as 'Kernel package with netns support has been installed on host 150.166.51.160. Because of the kernel update host mentioned above requires reboot.'^[[0m ^[[0;36mnotice: Finished catalog run in 5.87 seconds^[[0m 2013-08-13 07:44:32::ERROR::run_setup::889::root:: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 884, in main _main(confFile) File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 577, in _main runSequences() File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 554, in runSequences controller.runAllSequences() File "/usr/lib/python2.6/site-packages/packstack/installer/setup_controller.py", line 90, in runAllSequences sequence.run(self.CONF) File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 105, in run step.run(config=config) File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 52, in run raise SequenceError(str(ex)) SequenceError: Error during puppet run : err: /Stage[main]//Package[openstack-selinux]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-selinux' returned 1: Error: Package: openstack-selinux-0.1.2-10.el6ost.noarch (rhos3) I googled around and saw that others had received some similar but not quite the same errors when selinux was disabled (which is true on my system). Help please? Dave -------------------------------------------- Dave Raddatz Big Data Solutions and Performance Austin, TX (512) 249-0210 draddatz at sgi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From red at fedoraproject.org Tue Aug 13 19:13:10 2013 From: red at fedoraproject.org (Sandro "red" Mathys) Date: Tue, 13 Aug 2013 21:13:10 +0200 Subject: [rhos-list] Virbr0 Interface. In-Reply-To: <20130813083314.GA4432@redhat.com> References: <20130228192542.GB12318@redhat.com> <512FB6E5.1010901@redhat.com> <512FC464.1060107@redhat.com> <20130812202455.GH2107@redhat.com> <20130813003224.GA2124@redhat.com> <20130813083314.GA4432@redhat.com> Message-ID: On Tue, Aug 13, 2013 at 10:33 AM, Daniel P. Berrange wrote: > On Mon, Aug 12, 2013 at 08:32:24PM -0400, Dave Allan wrote: > > On Tue, Aug 13, 2013 at 02:00:32AM +0200, Sandro "red" Mathys wrote: > > > On Mon, Aug 12, 2013 at 10:24 PM, Dave Allan > wrote: > > > > > > > Note that on recent Fedora the default network is a separate package > > > > libvirt-daemon-config-network which should simply not be installed if > > > > the default network is not desirable. > > > > > > > > > > Interesting. So the upstream Nova Puppet module simply installs > libvirt and > > > openstack-nova-compute. Does that mean libvirt-daemon-config-network > will > > > not be installed? Or is libvirt now a metapackage that draws it all > in? And > > > if so, what package(s) should be installed instead? > > > > Yes, libvirt is now a metapackage. > > > > Double check me on this, but I think we just want > > libvirt-daemon-driver-qemu which pulls in only: > > Actally you'd be better off using libvirt-daemon-kvm - this pulls in > all the libvirt-daemon-driver-* that are required, along with the > suitable qemu-kvm RPM, still avoiding the default configs. > > Well, no matter what Packstack or the Puppet modules do, openstack-nova-compute has a dependency on the libvirt metapackage, pulling in 1) more packages than necessary and 2) libvirt-daemon-config-network, i.e. virbr0. That is, I tested with RDO Havana-2 on F19 but I'm pretty sure the same is true for RHOS (and Grizzly). Bug against Fedora Rawhide (and thereby RDO H-2) lifes at: https://bugzilla.redhat.com/show_bug.cgi?id=996715 -- Sandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevenca at cisco.com Mon Aug 19 18:06:52 2013 From: stevenca at cisco.com (Steven Carter (stevenca)) Date: Mon, 19 Aug 2013 18:06:52 +0000 Subject: [rhos-list] iSCSI LUNs from NetApp E-Series in Cinder Message-ID: <8A82B3ED85B0A945BC6EAD7ABD18062418633BDD@xmb-rcd-x04.cisco.com> I would like to present iSCSI LUNs that are exported to the openstack host up to the VM through Cinder as a raw device. The LUNs are served from a NetApp E5460 and they do not have the driver ready for that platform yet. In the meantime, I wanted to use cinder.volume.drivers.lvm.LVMISCSIDriver since the LUNs are already presented and I do not need to do anything fancy. I've been looking at every piece of documentation that I can find, but it is not intuitively obvious how to do this. Much of the documentation seems to be aimed at LUNs that are shared from local storage on the node, not an array. Is there some guidance for how to use iSCSI volumes from arrays in cinder? Thanks, Steven. -------------- next part -------------- An HTML attachment was scrubbed... URL: From draddatz at sgi.com Thu Aug 22 19:22:22 2013 From: draddatz at sgi.com (David Raddatz) Date: Thu, 22 Aug 2013 19:22:22 +0000 Subject: [rhos-list] start over using packstack? Message-ID: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> Hello, Is there a way to un-install RHOS 3.0 and start over using packstack? I had some issues during my installation, but I finally got packstack to work (after about 3-4 tries) on my all-in-one installation. However, I can't start the dashboard and /var/log/messages is showing several keystone authorization errors: nagios: SERVICE ALERT: 150.166.51.160;number of nova vm instances;WARNING;SOFT;2;ERROR: Invalid OpenStack Nova credentials. bizarro nagios: SERVICE ALERT: 150.166.51.160;number of cinder volumes;WARNING;SOFT;1;/usr/lib/python2.6/site-packages/cinderclient/shell.py:507: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 message = e.message ERROR: Invalid OpenStack Cinder credentials. nagios: SERVICE ALERT: 150.166.51.160;number of glance images;WARNING;SOFT;1;Unable to communicate with identity service: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}}. (HTTP 401) If I try to run keystone user-list (after sourcing the keystone_admin file), I get: # keystone user-list Unable to communicate with identity service: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}}. (HTTP 401) I found this link (http://openstack.redhat.com/forum/discussion/19/unable-to-login-at-dashboard-user-name-password-not-oke/p1) that suggested multiple packstack installation attempts might have resulted in a confused password setting for admin. I see that someone posted a "reset" script in there but there was also a mention of possibly incorporating something into packstack for re-installing in the future (this was back in April). Since I'm on a test machine, I think I'd rather just start fresh. Any pointers are appreciated, Dave -------------------------------------------- Dave Raddatz Big Data Solutions and Performance Austin, TX (512) 249-0210 draddatz at sgi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmaley at redhat.com Thu Aug 22 21:42:39 2013 From: dmaley at redhat.com (Dave Maley) Date: Thu, 22 Aug 2013 17:42:39 -0400 Subject: [rhos-list] start over using packstack? In-Reply-To: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> Message-ID: <1377207759.8743.26.camel@sideshowbob> Hi David, > Is there a way to un-install RHOS 3.0 and start over using packstack? There are 2 processes for this covered in the RHOS Getting Started Guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html/Getting_Started_Guide/appe-Getting_Started_Guide-Removing_PackStack_Deployments.html Cheers, ~Dave From draddatz at sgi.com Fri Aug 23 14:27:12 2013 From: draddatz at sgi.com (David Raddatz) Date: Fri, 23 Aug 2013 14:27:12 +0000 Subject: [rhos-list] start over using packstack? In-Reply-To: <1377207759.8743.26.camel@sideshowbob> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> <1377207759.8743.26.camel@sideshowbob> Message-ID: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B338@P-EXMB2-DC21.corp.sgi.com> Hi, Dave, Oops - isn't there an acronym for this about reading a manual? :) Thanks for the gentle reminder as I didn't look that far in my getting started guide to see it in the appendix. Dave -------------------------------------------- Dave Raddatz Big Data Solutions and Performance Austin, TX (512) 249-0210 draddatz at sgi.com > -----Original Message----- > From: Dave Maley [mailto:dmaley at redhat.com] > Sent: Thursday, August 22, 2013 4:43 PM > To: David Raddatz > Cc: rhos-list at redhat.com > Subject: Re: [rhos-list] start over using packstack? > > Hi David, > > > Is there a way to un-install RHOS 3.0 and start over using packstack? > > There are 2 processes for this covered in the RHOS Getting Started > Guide: > https://access.redhat.com/site/documentation/en- > US/Red_Hat_OpenStack/3/html/Getting_Started_Guide/appe- > Getting_Started_Guide-Removing_PackStack_Deployments.html > > Cheers, > ~Dave > From dmaley at redhat.com Fri Aug 23 15:25:20 2013 From: dmaley at redhat.com (Dave Maley) Date: Fri, 23 Aug 2013 11:25:20 -0400 Subject: [rhos-list] start over using packstack? In-Reply-To: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B338@P-EXMB2-DC21.corp.sgi.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> <1377207759.8743.26.camel@sideshowbob> <18CF1869BE7AB04DB1E4CC93FD43702A1B71B338@P-EXMB2-DC21.corp.sgi.com> Message-ID: <1377271520.1930.1.camel@sideshowbob> > > > Oops - isn't there an acronym for this about reading a manual? :) > Thanks for the gentle reminder as I didn't look that far in my getting > started guide to see it in the appendix. No worries at all! I happened to stumble upon this last week as I had the same need. And TBH the manuals weren't the 1st place I was looking either ;) Cheers, ~Dave From tvvcox at redhat.com Mon Aug 26 09:06:44 2013 From: tvvcox at redhat.com (Tomas Von Veschler) Date: Mon, 26 Aug 2013 11:06:44 +0200 Subject: [rhos-list] start over using packstack? In-Reply-To: <1377207759.8743.26.camel@sideshowbob> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> <1377207759.8743.26.camel@sideshowbob> Message-ID: <521B1AA4.3070700@redhat.com> On 08/22/2013 11:42 PM, Dave Maley wrote: > Hi David, > >> Is there a way to un-install RHOS 3.0 and start over using packstack? > > There are 2 processes for this covered in the RHOS Getting Started > Guide: > https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html/Getting_Started_Guide/appe-Getting_Started_Guide-Removing_PackStack_Deployments.html > Note the guide suggests: $ yum -y remove '*openstack*' This will match: kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch And without firmwares your nic most likely won't work. -- Tomas Von Veschler Senior Solution Architect Tel: +34 662 388 666 Red Hat, S.L. Madrid office From prashanth.prahal at gmail.com Mon Aug 26 11:14:58 2013 From: prashanth.prahal at gmail.com (Prashanth Prahalad) Date: Mon, 26 Aug 2013 16:44:58 +0530 Subject: [rhos-list] Cirros VM image DHCP issues Message-ID: Hi Folks, I just wanted to bounce this on the alias and get ideas on what could be going on. I've a quantum/OVS setup. I spin up the Cirros image and when the machine comes up it fails to get the DHCP address. I do see the DHCP request and the DHCP reply coming back from the DHCP server. Here's the tcpdump on the tap interface attached to the VM: [root at rhos3 ~]# *tcpdump -i tap97c9b343-4a* tcpdump: WARNING: tap97c9b343-4a: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap97c9b343-4a, link-type EN10MB (Ethernet), capture size 65535 bytes 04:09:47.852793 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 *04:09:47.857854 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* *04:09:47.857858 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* *04:09:47.858132 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: BOOTP/DHCP, Reply, length 322* *04:09:47.858395 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* *04:09:47.858397 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* *04:09:47.858493 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: BOOTP/DHCP, Reply, length 322* [root at rhos3 ~]# *ifconfig tap97c9b343-4a* tap97c9b343-4a Link encap:Ethernet HWaddr FE:16:3E:A6:EB:E6 inet6 addr: fe80::fc16:3eff:fea6:ebe6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:74 errors:0 dropped:0 overruns:0 frame:0 TX packets:10943 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:18144 (17.7 KiB) TX bytes:620606 (606.0 KiB) So any ideas why this DHCP reply is being rejected by the Cirros VM ? Any clue on how to debug this further. Regards, Prasahnth -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Mon Aug 26 11:26:51 2013 From: pmyers at redhat.com (Perry Myers) Date: Mon, 26 Aug 2013 07:26:51 -0400 Subject: [rhos-list] start over using packstack? In-Reply-To: <521B1AA4.3070700@redhat.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> <1377207759.8743.26.camel@sideshowbob> <521B1AA4.3070700@redhat.com> Message-ID: <521B3B7B.80201@redhat.com> On 08/26/2013 05:06 AM, Tomas Von Veschler wrote: > On 08/22/2013 11:42 PM, Dave Maley wrote: >> Hi David, >> >>> Is there a way to un-install RHOS 3.0 and start over using packstack? >> >> There are 2 processes for this covered in the RHOS Getting Started >> Guide: >> https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html/Getting_Started_Guide/appe-Getting_Started_Guide-Removing_PackStack_Deployments.html >> >> > > Note the guide suggests: > > $ yum -y remove '*openstack*' > > This will match: > kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch > > And without firmwares your nic most likely won't work. That particular kernel doesn't exist in RHOS yet, it's only in RDO. But yes, once it does exist in RHOS, the removal instructions will need to be amended. But a complete removal of RHOS should actually remove this, because this package is RHOS/RDO specific. But what should be done in this case is to remove: > [admin at el6-mgmt ~]$ s yum remove kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64 But first you need to be booted into another kernel. The system won't let you remove the running kernel. And then after removing the openstack.gre kernel and firmware, you'll need to reinstall the latest kernel-firmware available from the RHEL 6.4 repos. So the instructions should look like: * Reboot to non-RHOS/RDO kernel * yum remove *openstack* (Now that you're not booted to the OpenStack kernel, you can remove it) * Disable RHOS/RDO yum repos * yum install kernel-firmware Or something like that. Perry From pmyers at redhat.com Mon Aug 26 11:28:58 2013 From: pmyers at redhat.com (Perry Myers) Date: Mon, 26 Aug 2013 07:28:58 -0400 Subject: [rhos-list] Cirros VM image DHCP issues In-Reply-To: References: Message-ID: <521B3BFA.70109@redhat.com> On 08/26/2013 07:14 AM, Prashanth Prahalad wrote: > Hi Folks, > > I just wanted to bounce this on the alias and get ideas on what could be > going on. I've a quantum/OVS setup. I spin up the Cirros image and when > the machine comes up it fails to get the DHCP address. > > I do see the DHCP request and the DHCP reply coming back from the DHCP > server. > > Here's the tcpdump on the tap interface attached to the VM: > > [root at rhos3 ~]# *tcpdump -i tap97c9b343-4a* > tcpdump: WARNING: tap97c9b343-4a: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tap97c9b343-4a, link-type EN10MB (Ethernet), capture size > 65535 bytes > 04:09:47.852793 IP6 :: > ff02::16: HBH ICMP6, multicast listener report > v2, 1 group record(s), length 28 > *04:09:47.857854 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* > *04:09:47.857858 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* > *04:09:47.858132 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: > BOOTP/DHCP, Reply, length 322* > *04:09:47.858395 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* > *04:09:47.858397 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* > *04:09:47.858493 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: > BOOTP/DHCP, Reply, length 322* > > [root at rhos3 ~]# *ifconfig tap97c9b343-4a* > tap97c9b343-4a Link encap:Ethernet HWaddr FE:16:3E:A6:EB:E6 > inet6 addr: fe80::fc16:3eff:fea6:ebe6/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:74 errors:0 dropped:0 overruns:0 frame:0 > TX packets:10943 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:18144 (17.7 KiB) TX bytes:620606 (606.0 KiB) > > > So any ideas why this DHCP reply is being rejected by the Cirros VM ? > > Any clue on how to debug this further. What kernel are you running on the host? There is a known issue with the kernel shipped with RHOS that would cause this behavior. There is a fixed kernel available in RDO repositories right now (kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64) but it is not yet available via RHOS 3.0 repos. It should be available there in the next few weeks. Perry From tvvcox at redhat.com Mon Aug 26 11:57:15 2013 From: tvvcox at redhat.com (Tomas Von Veschler) Date: Mon, 26 Aug 2013 13:57:15 +0200 Subject: [rhos-list] start over using packstack? In-Reply-To: <521B3B7B.80201@redhat.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71B1CE@P-EXMB2-DC21.corp.sgi.com> <1377207759.8743.26.camel@sideshowbob> <521B1AA4.3070700@redhat.com> <521B3B7B.80201@redhat.com> Message-ID: <521B429B.6040506@redhat.com> On 08/26/2013 01:26 PM, Perry Myers wrote: > On 08/26/2013 05:06 AM, Tomas Von Veschler wrote: >> On 08/22/2013 11:42 PM, Dave Maley wrote: >>> Hi David, >>> >>>> Is there a way to un-install RHOS 3.0 and start over using packstack? >>> >>> There are 2 processes for this covered in the RHOS Getting Started >>> Guide: >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html/Getting_Started_Guide/appe-Getting_Started_Guide-Removing_PackStack_Deployments.html >>> >>> >> >> Note the guide suggests: >> >> $ yum -y remove '*openstack*' >> >> This will match: >> kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch >> >> And without firmwares your nic most likely won't work. > > That particular kernel doesn't exist in RHOS yet, it's only in RDO. > > But yes, once it does exist in RHOS, the removal instructions will need > to be amended. > > But a complete removal of RHOS should actually remove this, because this > package is RHOS/RDO specific. But what should be done in this case is > to remove: > >> [admin at el6-mgmt ~]$ s yum remove kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64 > > But first you need to be booted into another kernel. The system won't > let you remove the running kernel. > > And then after removing the openstack.gre kernel and firmware, you'll > need to reinstall the latest kernel-firmware available from the RHEL 6.4 > repos. > > So the instructions should look like: > > * Reboot to non-RHOS/RDO kernel I guess after reboot you'd be out of a valid kernel-firmware and thus no network to continue? Another way could be: * Disable RHOS repo * yum remove kernel-firmware && yum install kernel-firmware * Reboot * yum remove *openstack* // can we specify a list of packages instead? to avoid potentially uninstalling other customer packages > * yum remove *openstack* > (Now that you're not booted to the OpenStack kernel, you can remove > it) > * Disable RHOS/RDO yum repos > * yum install kernel-firmware > > Or something like that. > > Perry > -- Tomas Von Veschler Senior Solution Architect Tel: +34 662 388 666 Red Hat, S.L. Madrid office From roxenham at redhat.com Mon Aug 26 12:16:42 2013 From: roxenham at redhat.com (Rhys Oxenham) Date: Mon, 26 Aug 2013 13:16:42 +0100 Subject: [rhos-list] Cirros VM image DHCP issues In-Reply-To: <521B3BFA.70109@redhat.com> References: <521B3BFA.70109@redhat.com> Message-ID: <018AC617-CF5E-4079-A186-56AD36A2FC57@redhat.com> On 26 Aug 2013, at 12:28, Perry Myers wrote: > On 08/26/2013 07:14 AM, Prashanth Prahalad wrote: >> Hi Folks, >> >> I just wanted to bounce this on the alias and get ideas on what could be >> going on. I've a quantum/OVS setup. I spin up the Cirros image and when >> the machine comes up it fails to get the DHCP address. >> >> I do see the DHCP request and the DHCP reply coming back from the DHCP >> server. >> >> Here's the tcpdump on the tap interface attached to the VM: >> >> [root at rhos3 ~]# *tcpdump -i tap97c9b343-4a* >> tcpdump: WARNING: tap97c9b343-4a: no IPv4 address assigned >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on tap97c9b343-4a, link-type EN10MB (Ethernet), capture size >> 65535 bytes >> 04:09:47.852793 IP6 :: > ff02::16: HBH ICMP6, multicast listener report >> v2, 1 group record(s), length 28 >> *04:09:47.857854 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* >> *04:09:47.857858 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* >> *04:09:47.858132 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: >> BOOTP/DHCP, Reply, length 322* >> *04:09:47.858395 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* >> *04:09:47.858397 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* >> *04:09:47.858493 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: >> BOOTP/DHCP, Reply, length 322* >> >> [root at rhos3 ~]# *ifconfig tap97c9b343-4a* >> tap97c9b343-4a Link encap:Ethernet HWaddr FE:16:3E:A6:EB:E6 >> inet6 addr: fe80::fc16:3eff:fea6:ebe6/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:74 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:10943 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:500 >> RX bytes:18144 (17.7 KiB) TX bytes:620606 (606.0 KiB) >> >> >> So any ideas why this DHCP reply is being rejected by the Cirros VM ? >> >> Any clue on how to debug this further. > > What kernel are you running on the host? > > There is a known issue with the kernel shipped with RHOS that would > cause this behavior. There is a fixed kernel available in RDO > repositories right now > (kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64) but it is not yet > available via RHOS 3.0 repos. It should be available there in the next > few weeks. Hi Prashanth, Are you using Cirros 0.3.0? It has a bug where it completely ignores DHCP responses. Before continuing debugging, please try 0.3.1 and let us know whether this fixes it? wget http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img Cheers Rhys > > Perry > > _______________________________________________ > rhos-list mailing list > rhos-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhos-list From prashanth.prahal at gmail.com Mon Aug 26 17:28:35 2013 From: prashanth.prahal at gmail.com (Prashanth Prahalad) Date: Mon, 26 Aug 2013 22:58:35 +0530 Subject: [rhos-list] Cirros VM image DHCP issues In-Reply-To: <018AC617-CF5E-4079-A186-56AD36A2FC57@redhat.com> References: <521B3BFA.70109@redhat.com> <018AC617-CF5E-4079-A186-56AD36A2FC57@redhat.com> Message-ID: Thanks Rhys/Perry. To answer your questions: Rhys - I downloaded the cirros image you mentioned and that did the trick ! The only issue I see is that with the new Cirros 3.1, the VM takes a long time to come up (whereas 3.0 was pretty snappy). If you happen to know, could you point me to the bug or the link which mentions about this issue in Cirros. Perry - I'm running - [root at controller ~(keystone_admin)]# uname -a Linux controller 2.6.32-358.114.1.openstack.el6.x86_64 #1 SMP Wed Jul 3 02:11:25 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux Do you think this kernel could have the bug which you were mentioned ? Could you please reference the bug for this. I would really appreciate this. Interestingly, I'm running the same bits on the compute node and that seems fine (the VM picks up the DHCP reply just fine) Thanks again ! Prashanth On Mon, Aug 26, 2013 at 5:46 PM, Rhys Oxenham wrote: > > On 26 Aug 2013, at 12:28, Perry Myers wrote: > > > On 08/26/2013 07:14 AM, Prashanth Prahalad wrote: > >> Hi Folks, > >> > >> I just wanted to bounce this on the alias and get ideas on what could be > >> going on. I've a quantum/OVS setup. I spin up the Cirros image and when > >> the machine comes up it fails to get the DHCP address. > >> > >> I do see the DHCP request and the DHCP reply coming back from the DHCP > >> server. > >> > >> Here's the tcpdump on the tap interface attached to the VM: > >> > >> [root at rhos3 ~]# *tcpdump -i tap97c9b343-4a* > >> tcpdump: WARNING: tap97c9b343-4a: no IPv4 address assigned > >> tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > >> listening on tap97c9b343-4a, link-type EN10MB (Ethernet), capture size > >> 65535 bytes > >> 04:09:47.852793 IP6 :: > ff02::16: HBH ICMP6, multicast listener report > >> v2, 1 group record(s), length 28 > >> *04:09:47.857854 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* > >> *04:09:47.857858 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 280* > >> *04:09:47.858132 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: > >> BOOTP/DHCP, Reply, length 322* > >> *04:09:47.858395 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* > >> *04:09:47.858397 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > >> Request from fa:16:3e:a6:eb:e6 (oui Unknown), length 292* > >> *04:09:47.858493 IP 192.168.10.3.bootps > 192.168.10.6.bootpc: > >> BOOTP/DHCP, Reply, length 322* > >> > >> [root at rhos3 ~]# *ifconfig tap97c9b343-4a* > >> tap97c9b343-4a Link encap:Ethernet HWaddr FE:16:3E:A6:EB:E6 > >> inet6 addr: fe80::fc16:3eff:fea6:ebe6/64 Scope:Link > >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >> RX packets:74 errors:0 dropped:0 overruns:0 frame:0 > >> TX packets:10943 errors:0 dropped:0 overruns:0 carrier:0 > >> collisions:0 txqueuelen:500 > >> RX bytes:18144 (17.7 KiB) TX bytes:620606 (606.0 KiB) > >> > >> > >> So any ideas why this DHCP reply is being rejected by the Cirros VM ? > >> > >> Any clue on how to debug this further. > > > > What kernel are you running on the host? > > > > There is a known issue with the kernel shipped with RHOS that would > > cause this behavior. There is a fixed kernel available in RDO > > repositories right now > > (kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64) but it is not yet > > available via RHOS 3.0 repos. It should be available there in the next > > few weeks. > > Hi Prashanth, > > Are you using Cirros 0.3.0? It has a bug where it completely ignores DHCP > responses. Before continuing debugging, please try 0.3.1 and let us know > whether this fixes it? > > wget http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img > > Cheers > Rhys > > > > > > Perry > > > > _______________________________________________ > > rhos-list mailing list > > rhos-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rhos-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Mon Aug 26 17:45:28 2013 From: pmyers at redhat.com (Perry Myers) Date: Mon, 26 Aug 2013 13:45:28 -0400 Subject: [rhos-list] Cirros VM image DHCP issues In-Reply-To: References: <521B3BFA.70109@redhat.com> <018AC617-CF5E-4079-A186-56AD36A2FC57@redhat.com> Message-ID: <521B9438.2080902@redhat.com> On 08/26/2013 01:28 PM, Prashanth Prahalad wrote: > Thanks Rhys/Perry. > > To answer your questions: > > Rhys - I downloaded the cirros image you mentioned and that did the > trick ! The only issue I see is that with the new Cirros 3.1, the VM > takes a long time to come up (whereas 3.0 was pretty snappy). If you > happen to know, could you point me to the bug or the link which mentions > about this issue in Cirros. > > Perry - I'm running - > > [root at controller ~(keystone_admin)]# uname -a > Linux controller 2.6.32-358.114.1.openstack.el6.x86_64 #1 SMP Wed > Jul 3 02:11:25 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux > > > Do you think this kernel could have the bug which you were mentioned ? > Could you please reference the bug for this. I would really appreciate > this. I don't know the bz# offhand, but that kernel is the latest released kernel for RHOS and it does have some bugs around using Quantum. I was never able to get guests to get dhcp addresses when using that kernel. Instead I have been using: http://repos.fedorapeople.org/repos/openstack/openstack-grizzly/epel-6/kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64.rpm Which unfortunately is only available on RDO right now. But we will be releasing a new RHOS kernel in 3.0 repos in the next few weeks which will have the same fixes as what is in RDO. > Interestingly, I'm running the same bits on the compute node and that > seems fine (the VM picks up the DHCP reply just fine) From roxenham at redhat.com Tue Aug 27 04:48:14 2013 From: roxenham at redhat.com (Rhys Oxenham) Date: Tue, 27 Aug 2013 00:48:14 -0400 (EDT) Subject: [rhos-list] Cirros VM image DHCP issues In-Reply-To: <521B9438.2080902@redhat.com> References: <521B3BFA.70109@redhat.com> <018AC617-CF5E-4079-A186-56AD36A2FC57@redhat.com> <521B9438.2080902@redhat.com> Message-ID: <9C3E8F27-E3BB-4AEA-B650-00967544BC2D@redhat.com> On 26 Aug 2013, at 20:45, Perry Myers wrote: > On 08/26/2013 01:28 PM, Prashanth Prahalad wrote: >> Thanks Rhys/Perry. >> >> To answer your questions: >> >> Rhys - I downloaded the cirros image you mentioned and that did the >> trick ! The only issue I see is that with the new Cirros 3.1, the VM >> takes a long time to come up (whereas 3.0 was pretty snappy). If you >> happen to know, could you point me to the bug or the link which mentions >> about this issue in Cirros. Great! Are you running the metadata service? I suspect that if you're not it is waiting on the metadata service and will eventually time out. Does it give any indication of this upon boot? Thanks Rhys >> >> Perry - I'm running - >> >> [root at controller ~(keystone_admin)]# uname -a >> Linux controller 2.6.32-358.114.1.openstack.el6.x86_64 #1 SMP Wed >> Jul 3 02:11:25 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux >> >> >> Do you think this kernel could have the bug which you were mentioned ? >> Could you please reference the bug for this. I would really appreciate >> this. > > I don't know the bz# offhand, but that kernel is the latest released > kernel for RHOS and it does have some bugs around using Quantum. I was > never able to get guests to get dhcp addresses when using that kernel. > > Instead I have been using: > http://repos.fedorapeople.org/repos/openstack/openstack-grizzly/epel-6/kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64.rpm > > Which unfortunately is only available on RDO right now. But we will be > releasing a new RHOS kernel in 3.0 repos in the next few weeks which > will have the same fixes as what is in RDO. > >> Interestingly, I'm running the same bits on the compute node and that >> seems fine (the VM picks up the DHCP reply just fine) From lchristoph at arago.de Tue Aug 27 11:29:15 2013 From: lchristoph at arago.de (Lutz Christoph) Date: Tue, 27 Aug 2013 11:29:15 +0000 Subject: [rhos-list] Remote Cinder access Message-ID: Hi! I'm in the last tests for a three node RDO setup, and I found that with the current default setup, qemu-kvm can't access a volume: qemu-kvm: -drive file=/dev/disk/by-path/ip-192.168.104.61:3260-iscsi-iqn.2010-10.org.openstack:volume-229b80d0-ad10-4a3b-b022-d632de368001-lun-1,if=none,id=drive-virtio-disk0,format=raw,serial=229b80d0-ad10-4a3b-b022-d632de368001,cache=none: could not open disk image /dev/disk/by-path/ip-192.168.104.61:3260-iscsi-iqn.2010-10.org.openstack:volume-229b80d0-ad10-4a3b-b022-d632de368001-lun-1: Permission denied The device looks just like any other disk device: lrwxrwxrwx. 1 root root 9 Aug 27 10:40 /dev/disk/by-path/ip-192.168.104.61:3260-iscsi-iqn.2010-10.org.openstack:volume-229b80d0-ad10-4a3b-b022-d632de368001-lun-1 -> ../../sdj brw-rw----. 1 root disk 8, 144 Aug 27 10:40 /dev/sdj qemu is running under the "nova" user (it is running as "qemu" on an all-in-one server). When I added the "disk" group to the "nova" user, the problem went away. Doing the same on the all-in-one machine did not have this problem, but them access is directly to the LV, not via iSCSI, and the user is different, though it does not have the "disk" group attached. Now, I'm wondering if adding the "disk" group is the right thing to so, considering that the all-in-one does not need this, or there is a more elegant solution. Best regards / Mit freundlichen Gr??en Lutz Christoph -- Lutz Christoph arago Institut f?r komplexes Datenmanagement AG Eschersheimer Landstra?e 526 - 532 60433 Frankfurt am Main eMail: lchristoph at arago.de - www: http://www.arago.de Tel: 0172/6301004 Mobil: 0172/6301004 [http://www.arago.net/wp-content/uploads/2013/06/EmailSignatur1.png] -- Bankverbindung: Frankfurter Sparkasse, BLZ: 500 502 01, Kto.-Nr.: 79343 Vorstand: Hans-Christian Boos, Martin Friedrich Vorsitzender des Aufsichtsrats: Dr. Bernhard Walther Sitz: Kronberg im Taunus - HRB 5731 - Registergericht: K?nigstein i.Ts Ust.Idnr. DE 178572359 - Steuernummer 2603 003 228 43435 -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy.krenz at overturenetworks.com Thu Aug 29 17:57:49 2013 From: randy.krenz at overturenetworks.com (Randy Krenz) Date: Thu, 29 Aug 2013 17:57:49 +0000 Subject: [rhos-list] issue with metadata server Message-ID: <56783E33DC30D14B8AB6151A060A187732EDEB40@mbx024-e1-nj-2.exch024.domain.local> I'm experiencing an issue with the quantum metadata server. I seem to be having the same issue on either the RDO or Redhat-supported versions of OpenStack. I'm trying to provide the metadata service on an isolated virtual network via the DHCP namespace. As such, I have set "enable_isolated_metadata = True" in dhcp_agent.ini. When I start a virtual machine on this network, the virtual machine fails to reach the metadata service. If I login to the virtual machine, I see that the DHCP server has added a route which says the DHCP server IP address is the route to 169.254.169.254, as expected. I also see that the quantum-metadata-agent is running on the bare-metal Linux and is responding to curl requests on port 8775. What I don't see is quantum-ns-metadata-proxy running, which I thought was supposed to be spawned with the DHCP server. Probably some kind of configuration error but just can't put my finger on it. Don't see any obvious issues in /var/log/quantum. Any help appreciated. Randy Here is my dhcp_agent.ini: [DEFAULT] # Show more verbose log output (sets INFO log level output). # verbose = True # Show debugging output in log (sets DEBUG log level output). # debug = False debug = False # Where to store dnsmasq state files. This directory must be writable by the # user executing the agent. The value below is compatible with a default # devstack installation. # state_path = /var/lib/quantum state_path = /var/lib/quantum # The DHCP agent will resync its state with Quantum to recover from any # transient notification or rpc errors. The interval is number of # seconds between attempts. # resync_interval = 5 resync_interval = 30 # The DHCP agent requires that an interface driver be set. Choose the # one that best matches you plugin. There is no default. # interface_driver = # # OVS # interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver # LinuxBridge # interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver # Ryu # interface_driver = quantum.agent.linux.interface.RyuInterfaceDriver # The agent can use other DHCP drivers. Dnsmasq is the simplest and requires # no additional setup of the DHCP server. # dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq use_namespaces = False enable_isolated_metadata = True This email and attachments may contain privileged or confidential information intended only for the addressee(s) indicated. The sender does not waive any of its rights, privileges or protections respecting this information. If you are not the named addressee, an employee, or agent responsible for sending this message to the named addressee (or this message was received by mistake), you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If received in error, please notify us immediately by e-mail, discard any paper copies and delete all electronic files of the email. Computer viruses can be transmitted via email. The recipient should check this email and any attachments for viruses. Email transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender accepts no liability for any damage caused by any transmitted viruses or errors or omissions in the contents of this message. Overture Networks, Inc. 637 Davis Drive, Morrisville, NC USA 27560 www.overturenetworks.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From draddatz at sgi.com Thu Aug 29 19:04:02 2013 From: draddatz at sgi.com (David Raddatz) Date: Thu, 29 Aug 2013 19:04:02 +0000 Subject: [rhos-list] horizon log in via https not working Message-ID: <18CF1869BE7AB04DB1E4CC93FD43702A1B71BB06@P-EXMB2-DC21.corp.sgi.com> Hello, I got my RHOS 3.0 packstack all-in-one install to complete without errors but I can't use my browser to get to the horizon web interface if I try to use the HTTPS address. If I use the HTTP address, then it works. The INFO message after packstack finishes points me to the HTTPS URL but that didn't work. I have CONFIG_HORIZON_SSL=y in my answers file that I used during the installation. I looked at the docs.openstack.org doc where it talks about installing openstack dashboard and enabling it for HTTPS, BUT it refers to files that don't appear to exist on my system: /etc/openstack-dashboard/local_settings.py /etc/apache2/ports.conf /etc/apache2/conf.d/openstack-dashboard.conf I'm reluctant to just create those files figuring that something else isn't configured correctly. Where else can I look to see what is wrong? Any ideas on what I have wrong here? Thanks, Dave -------------------------------------------- Dave Raddatz Big Data Solutions and Performance Austin, TX (512) 249-0210 draddatz at sgi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lchristoph at arago.de Thu Aug 29 19:27:28 2013 From: lchristoph at arago.de (Lutz Christoph) Date: Thu, 29 Aug 2013 19:27:28 +0000 Subject: [rhos-list] issue with metadata server In-Reply-To: <56783E33DC30D14B8AB6151A060A187732EDEB40@mbx024-e1-nj-2.exch024.domain.local> References: <56783E33DC30D14B8AB6151A060A187732EDEB40@mbx024-e1-nj-2.exch024.domain.local> Message-ID: <98f39883fce14649b16623d1b3178290@AMSPR07MB145.eurprd07.prod.outlook.com> Hello! I worked with the 169.254.169.254 aka metadata server quite a bit. The first thing I discovered is that there is only an IPtables redirect for access to port 80, which means that access *must* go through an OpenStack router, otherwise the ARP requests seek 169.254.169.254, not the router address. This happened for me when I used an external router, which of course does not redirect to the metadata server. So I set up a secondary router and passed a route to 169.254.0.0/16 to the VMs as an explicit route (may not work with some DHCP clients). I can't log into the computer center right now, so I can't check for the process you are missing, but maybe the above will give you an alternate path to pursue. Maybe I misunderstood you, and this does not apply. Then I apologize for wasting your time. Best regards / Mit freundlichen Gr??en Lutz Christoph -- Lutz Christoph arago Institut f?r komplexes Datenmanagement AG Eschersheimer Landstra?e 526 - 532 60433 Frankfurt am Main eMail: lchristoph at arago.de - www: http://www.arago.de Tel: 0172/6301004 Mobil: 0172/6301004 [http://www.arago.net/wp-content/uploads/2013/06/EmailSignatur1.png] -- Bankverbindung: Frankfurter Sparkasse, BLZ: 500 502 01, Kto.-Nr.: 79343 Vorstand: Hans-Christian Boos, Martin Friedrich Vorsitzender des Aufsichtsrats: Dr. Bernhard Walther Sitz: Kronberg im Taunus - HRB 5731 - Registergericht: K?nigstein i.Ts Ust.Idnr. DE 178572359 - Steuernummer 2603 003 228 43435 ________________________________ Von: rhos-list-bounces at redhat.com im Auftrag von Randy Krenz Gesendet: Donnerstag, 29. August 2013 19:57 An: rhos-list at redhat.com Betreff: [rhos-list] issue with metadata server I?m experiencing an issue with the quantum metadata server. I seem to be having the same issue on either the RDO or Redhat-supported versions of OpenStack. I?m trying to provide the metadata service on an isolated virtual network via the DHCP namespace. As such, I have set ?enable_isolated_metadata = True? in dhcp_agent.ini. When I start a virtual machine on this network, the virtual machine fails to reach the metadata service. If I login to the virtual machine, I see that the DHCP server has added a route which says the DHCP server IP address is the route to 169.254.169.254, as expected. I also see that the quantum-metadata-agent is running on the bare-metal Linux and is responding to curl requests on port 8775. What I don?t see is quantum-ns-metadata-proxy running, which I thought was supposed to be spawned with the DHCP server. Probably some kind of configuration error but just can?t put my finger on it. Don?t see any obvious issues in /var/log/quantum. Any help appreciated. Randy Here is my dhcp_agent.ini: [DEFAULT] # Show more verbose log output (sets INFO log level output). # verbose = True # Show debugging output in log (sets DEBUG log level output). # debug = False debug = False # Where to store dnsmasq state files. This directory must be writable by the # user executing the agent. The value below is compatible with a default # devstack installation. # state_path = /var/lib/quantum state_path = /var/lib/quantum # The DHCP agent will resync its state with Quantum to recover from any # transient notification or rpc errors. The interval is number of # seconds between attempts. # resync_interval = 5 resync_interval = 30 # The DHCP agent requires that an interface driver be set. Choose the # one that best matches you plugin. There is no default. # interface_driver = # # OVS # interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver # LinuxBridge # interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver # Ryu # interface_driver = quantum.agent.linux.interface.RyuInterfaceDriver # The agent can use other DHCP drivers. Dnsmasq is the simplest and requires # no additional setup of the DHCP server. # dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq use_namespaces = False enable_isolated_metadata = True This email and attachments may contain privileged or confidential information intended only for the addressee(s) indicated. The sender does not waive any of its rights, privileges or protections respecting this information. If you are not the named addressee, an employee, or agent responsible for sending this message to the named addressee (or this message was received by mistake), you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If received in error, please notify us immediately by e-mail, discard any paper copies and delete all electronic files of the email. Computer viruses can be transmitted via email. The recipient should check this email and any attachments for viruses. Email transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender accepts no liability for any damage caused by any transmitted viruses or errors or omissions in the contents of this message. Overture Networks, Inc. 637 Davis Drive, Morrisville, NC USA 27560 www.overturenetworks.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at redhat.com Fri Aug 30 11:30:05 2013 From: mrunge at redhat.com (Matthias Runge) Date: Fri, 30 Aug 2013 13:30:05 +0200 Subject: [rhos-list] horizon log in via https not working In-Reply-To: <18CF1869BE7AB04DB1E4CC93FD43702A1B71BB06@P-EXMB2-DC21.corp.sgi.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71BB06@P-EXMB2-DC21.corp.sgi.com> Message-ID: <5220823D.3040507@redhat.com> On 29/08/13 21:04, David Raddatz wrote: > Hello, > > > > I got my RHOS 3.0 packstack all-in-one install to complete without > errors but I can?t use my browser to get to the horizon web interface if > I try to use the HTTPS address. If I use the HTTP address, then it > works. The INFO message after packstack finishes points me to the HTTPS > URL but that didn?t work. I have CONFIG_HORIZON_SSL=y in my answers > file that I used during the installation. > > > > I looked at the docs.openstack.org doc where it talks about installing > openstack dashboard and enabling it for HTTPS, BUT it refers to files > that don?t appear to exist on my system: > > |/etc/openstack-dashboard/local_settings.py| > > |/etc/apache2/ports.conf| > > |/etc/apache2/conf.d/openstack-dashboard.conf| > > Those files may exist on Ubuntu systems, and I think I have fixed that once at upstream docs. Sadly, upstream docs are organized in a confusing way here. You might want to check the docs for RHOS-3.0: https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html/Installation_and_Configuration_Guide/Configuring_Secured_Deployment_HTTPS.html Is a firewall active, and if yes, is port 443 open? Is your httpd listening on 443? Matthias From draddatz at sgi.com Fri Aug 30 14:07:13 2013 From: draddatz at sgi.com (David Raddatz) Date: Fri, 30 Aug 2013 14:07:13 +0000 Subject: [rhos-list] horizon log in via https not working In-Reply-To: <5220823D.3040507@redhat.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B71BB06@P-EXMB2-DC21.corp.sgi.com> <5220823D.3040507@redhat.com> Message-ID: <18CF1869BE7AB04DB1E4CC93FD43702A1B71BC02@P-EXMB2-DC21.corp.sgi.com> Hi, Matthias, Thanks for the response. Yeah - the doc.openstack.org is probably geared towards Ubuntu... I'll take a look at the red hat document (been looking at it this morning) but now I have some probably dumb questions as I'm a newbie in all this. BTW, it looks like the firewall is active and not listening to 443. I was under the impression that using packstack would make it easier to configure Red Hat OpenStack. Why does the HTTPS access method not work when the HTTPS URL is the URL that is given after the packstack installation completes? If I have to go back and manually configure Horizon to enable the SSL/HTTPS support, then what is the value of packstack in this particular case? Wouldn't specifying CONFIG_HORIZON_SSL=y tell packstack to configure things for me? Or, maybe I didn't have something set up in my answer file correctly? After all that - since this is a non-production test environment, I'm wondering is it even necessary to configure the HTTPS support? I mean, besides going through the process to gain the experience of configuring it, I probably don't care if I can't access Horizon using the HTTPS method - right? It was just confusing when I got the message after the installation to use that URL (and it didn't work) that took me down this path... Dave -------------------------------------------- Dave Raddatz Big Data Solutions and Performance Austin, TX (512) 249-0210 draddatz at sgi.com > -----Original Message----- > From: rhos-list-bounces at redhat.com [mailto:rhos-list- > bounces at redhat.com] On Behalf Of Matthias Runge > Sent: Friday, August 30, 2013 6:30 AM > To: rhos-list at redhat.com > Subject: Re: [rhos-list] horizon log in via https not working > > On 29/08/13 21:04, David Raddatz wrote: > > Hello, > > > > > > > > I got my RHOS 3.0 packstack all-in-one install to complete without > > errors but I can't use my browser to get to the horizon web interface > > if I try to use the HTTPS address. If I use the HTTP address, then it > > works. The INFO message after packstack finishes points me to the > > HTTPS URL but that didn't work. I have CONFIG_HORIZON_SSL=y in my > > answers file that I used during the installation. > > > > > > > > I looked at the docs.openstack.org doc where it talks about installing > > openstack dashboard and enabling it for HTTPS, BUT it refers to files > > that don't appear to exist on my system: > > > > |/etc/openstack-dashboard/local_settings.py| > > > > |/etc/apache2/ports.conf| > > > > |/etc/apache2/conf.d/openstack-dashboard.conf| > > > > > Those files may exist on Ubuntu systems, and I think I have fixed that once at > upstream docs. Sadly, upstream docs are organized in a confusing way here. > > You might want to check the docs for RHOS-3.0: > https://access.redhat.com/site/documentation/en- > US/Red_Hat_OpenStack/3/html/Installation_and_Configuration_Guide/Con > figuring_Secured_Deployment_HTTPS.html > > Is a firewall active, and if yes, is port 443 open? > Is your httpd listening on 443? > > Matthias > > > _______________________________________________ > rhos-list mailing list > rhos-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhos-list From gfidente at redhat.com Fri Aug 30 14:20:32 2013 From: gfidente at redhat.com (Giulio Fidente) Date: Fri, 30 Aug 2013 16:20:32 +0200 Subject: [rhos-list] error during install using packstack In-Reply-To: <18CF1869BE7AB04DB1E4CC93FD43702A1B710225@P-EXMB2-DC21.corp.sgi.com> References: <18CF1869BE7AB04DB1E4CC93FD43702A1B710225@P-EXMB2-DC21.corp.sgi.com> Message-ID: <5220AA30.2060106@redhat.com> On 08/13/2013 05:02 PM, David Raddatz wrote: > openstack-selinux-0.1.2-10.el6ost.noarch (rhos3) > > Requires: selinux-policy-targeted >= 3.7.19-195.el6_4.2 > > Installed: selinux-policy-targeted-3.7.19-195.el6.noarch hi David, I think this error means that openstack-selinux requires a version of selinux-policy-target newer than what you have and couldn't find it What you have installed should be the version packaged with the stock rhel 6.4 while rhos 3 requires a newer version of selinux-policy-targeted which is distributed via rhn; so you should register your system on rhn (or maybe use centos or some derivatives) -- Giulio Fidente GPG KEY: 08D733BA | IRC: giulivo From andrey at xdel.ru Fri Aug 30 18:20:14 2013 From: andrey at xdel.ru (Andrey Korolyov) Date: Fri, 30 Aug 2013 22:20:14 +0400 Subject: [rhos-list] Kernel/userspace tools security updates Message-ID: Hello, Is there an existing milestone for getting security updates for RDO packages in predictable times? For example, imagining if such practice exists to date, what will be timelines for RHSA-2013-1173?