July 2014 - dev - Rdo List Archives

by John Eckersberg

(In the spirit of "Concerning Hobbits") Ryan O'Hara and I have been investigating RabbitMQ as it pertains to RDO recently. There has been a lot of discussion on several disparate threads, so I wanted to try and capture it on the list for the benefit of everyone. Ryan has been working on getting RabbitMQ running in a multi-node HA configuration. I won't steal his thunder, and he can speak to it better than I can, so I'll defer to him on the details. As for me, I've been working on el7 support and bug squashing along the way. The first bug[1] causes the daemon to load incredibly slow, or outright fail by timing out. This is due to the SELinux policy disallowing name_bind on ports lower than 32768. RabbitMQ tries to name_bind to a port starting at 10000, and increments if it fails. So if you have SELinux in enforcing mode, you'll get 22768 AVC denials in the log before it finally starts. The second bug[2] causes the daemon to intermittently fail to start due to a race condition in the creation of the erlang cookie file. This happens only the first time the service starts. Really this is an Erlang bug, but there's a workaround for the RabbitMQ case. I've submitted patches for both issues. Until those get merged in, I've rebuilt[3] RabbitMQ for F20 which includes the fixes. Beyond bugs, I've also built out RabbitMQ and all the build/runtime dependencies for el7. I have a yum repo[4] on my fedorapeople page containing all the bits. This is all the stuff that is presently missing from EPEL7. In time, I would hope the maintainers build all this stuff, but for now it'll work for testing. You will also need the EPEL 7 Beta repository[5] enabled. As a side note, I built everything using mock with a local override repo on my workstation. I've not used copr before but it seems relevant to this sort of thing, so if it's any benefit I'll look to rebuilt the el7 stack there for easier consumption. Hopefully this helps get the discussion into one place, and provide a baseline for further investigation by everyone interested in RabbitMQ. John. --- [1] Is really two bugzillas, but the same bug: [1a] https://bugzilla.redhat.com/show_bug.cgi?id=998682 [1b] https://bugzilla.redhat.com/show_bug.cgi?id=1032595 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1059913 [3] http://jeckersb.fedorapeople.org/rabbitmq-server-3.1.5-3.fc20.noarch.rpm [4] http://jeckersb.fedorapeople.org/rabbitmq-el7/ [5] http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/

10 years, 6 months

6
11
0 / 0

[Rdo-list] mysqld failure on --allinone, centos7

by Rich Bowen

I'm running `packstack --allinone` on a fresh install of the new CentOS7, and I'm getting a failure at: 192.168.0.176_mysql.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 192.168.0.176_mysql.pp Error: Could not enable mysqld: You will find full trace in log /var/tmp/packstack/20140708-092703-ZMkytw/manifests/192.168.0.176_mysql.pp.log Please check log file /var/tmp/packstack/20140708-092703-ZMkytw/openstack-setup.log for more information The log message is: Notice: /Stage[main]/Neutron::Db::Mysql/Mysql::Db[neutron]/Database_grant[neutron@127.0.0.1/neutron]: Dependency Service[mysqld] has failures: true Warning: /Stage[main]/Neutron::Db::Mysql/Mysql::Db[neutron]/Database_grant[neutron@127.0.0.1/neutron]: Skipping because of failed dependencies mysqld was successfully installed, and is running. Before I start digging deeper, I wondered if this is something that's already been encountered. Thanks. -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

10 years, 7 months

6
13
0 / 0

[Rdo-list] foreman-installer puppet problems: " Error 400 on SERVER: Must pass admin_password to Class[Quickstack::Nova]"

by Jonas Hagberg

Hej I have installed foreman-installer from yum repo icehouce el6 on Scientific linux 6.5 I got foreman up and running and got hostgroups and smart parameters. But when assigning a node to a hostgroup (Neutron controller or neutron compute) and running puppet I get the following error. err: Could not retrieve catalog from remote server: Error 400 on SERVER: Must pass admin_password to Class[Quickstack::Nova] at /usr/share/openstack-foreman-installer/puppet/modules/quickstack/manifests/nova.pp:65 on "fqdn" admin_password is set in hostgroup. Any tips on where the problem could be? Cheers -- Jonas Hagberg BILS - Bioinformatics Infrastructure for Life Sciences - http://bils.se e-mail: jonas.hagberg(a)bils.se, jonas.hagberg(a)scilifelab.se phone: +46-(0)70 6683869 address: SciLifeLab, Box 1031, 171 21 Solna, Sweden

10 years, 9 months

2
3
0 / 0

[Rdo-list] Metadata block until restart iptables

by Lakmal Warusawithana

Hi, Configured multi node RDO setup on centos 6.5 with gre tunneling. Instances are spin up correctly but metadata not received to instances. When restart the iptables on compute node, metadata received only instances that spin up in that compute node. Seems like iptables issue, wonder how to figure it out. Is anyone notice this? highly appreciate your help. thanks -- Lakmal Warusawithana

10 years, 9 months

2
1
0 / 0

[Rdo-list] [RDO][Instack] heat is not able to create stack with instack

by Pradeep Kumar Surisetty

Hi All I have been trying to set instack with RDO. I have successfully installed undercloud and moving on to overcloud. Now, when I run "instack-deploy-overcloud", I get the following error: |+ OVERCLOUD_YAML_PATH=overcloud.yaml + heat stack-create-f overcloud.yaml-PAdminToken=b003d63242f5db3e1ad4864ae66911e02ba19bcb-PAdminPassword=7bfe4d4a18280752ad07f259a69a3ed00db2ab44 -PCinderPassword=df0893b4355f3511a6d67538dd592d02d1bc11d3-PGlancePassword=066f65f878157b438a916ccbd44e0b7037ee118f -PHeatPassword=58fda0e4d6708e0164167b11fe6fca6ab6b35ec6 -PNeutronPassword=80853ad029feb77bb7c60d035542f21aa5c24177 -PNovaPassword=331474580be53b78e40c91dfdfc2323578a035e7 -PNeutronPublicInterface=eth0-PSwiftPassword=b0eca57b45ebf3dd5cae071dc3880888fb1d4840-PSwiftHashSuffix=a8d87f3952d6f91da589fbef801bb92141fd1461-PNovaComputeLibvirtType=qemu-P'GlanceLogFile='\'''\''' -PNeutronDnsmasqOptions=dhcp-option-force=26,1400 overcloud +--------------------------------------+------------+--------------------+----------------------+ | id| stack_name| stack_status| creation_time| +--------------------------------------+------------+--------------------+----------------------+ | 0ca028e7-682b-41ef-8af0-b2eb67bee272| overcloud| CREATE_IN_PROGRESS| 2014-07-18T10:50:48Z | +--------------------------------------+------------+--------------------+----------------------+ + tripleo wait_for_stack_ready220 10 overcloud Command output matched'CREATE_FAILED'. Exiting... |Now, i understand that the stack isn't being created. So, I tried to check out the state of the stack: |[stack@localhost~]$ heat stack-list +--------------------------------------+------------+---------------+----------------------+ | id| stack_name| stack_status| creation_time| +--------------------------------------+------------+---------------+----------------------+ | 0ca028e7-682b-41ef-8af0-b2eb67bee272| overcloud| CREATE_FAILED| 2014-07-18T10:50:48Z | +--------------------------------------+------------+---------------+----------------------+ | i even tried to create stack manually, but ended up getting the same error. Update: Here is the heat log: |2014-07-18 06:51:11.884 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:12.921 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:16.058 30750 ERROR heat.engine.resource[-] CREATE: Server "SwiftStorage0" [07e42c3d-0f1b-4bb9-b980-ffbb74ac770d] Stack "overcloud" [0ca028e7-682b-41ef-8af0-b2eb67bee272] 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourceTraceback (most recent calllast): 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourceFile "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line420, in _do_action 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourcewhile not check(handle_data): 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourceFile "/usr/lib/python2.7/site-packages/heat/engine/resources/server.py", line545, in check_create_complete 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourcereturn self._check_active(server) 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourceFile "/usr/lib/python2.7/site-packages/heat/engine/resources/server.py", line561, in _check_active 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourceraise exc 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resourceError: Creation of server overcloud-SwiftStorage0-qdjqbif6peva failed. 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource 2014-07-18 06:51:16.255 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:16.939 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:17.368 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:17.638 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:18.158 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back tousing default 2014-07-18 06:51:18.613 30750 WARNING heat.common.keystoneclient[-] stack_user_domain IDnot set in heat.conf falling back... Earlier posted in wrong/different forum. Ref: https://ask.openstack.org/en/question/43017/heat-is-not-able-to-create-st... | --Pradeep

10 years, 9 months

3
5
0 / 0

[Rdo-list] Issues with rdo-release-4 and external networking / br-tun

by uberj

Hello, I'm attempting to get rdo working on Centos6.5 with external networking. I am following the steps outlined on http://openstack.redhat.com/Neutron_with_existing_external_network To install openstack, I'm running the following commands: sudo yum -y update sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm sudo yum install -y openstack-packstack packstack --allinone --provision-all-in-one-ovs-bridge=n --os-client-install=y --os-heat-install=y After it completes I do 'tail -f /var/log/neutron/*.log' and then 'service neutron-openvswitch-agent restart'. In the neutron log I see the following errors: 2014-07-18 16:06:03.255 28794 ERROR neutron.agent.linux.ovs_lib [req-2fc4abd3-483a-4476-b14d-78c09b04368c None] Unable to execute ['ovs-ofctl', 'del-flows', 'br-tun']. Exception: Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'del-flows', 'br-tun'] Exit code: 1 Stdout: '' Stderr: 'ovs-ofctl: br-tun is not a bridge or a socket\n' 2014-07-18 16:06:03.325 28794 ERROR neutron.agent.linux.ovs_lib [req-2fc4abd3-483a-4476-b14d-78c09b04368c None] Unable to execute ['ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=1,in_port=1,actions=resubmit(,1)']. Exception: Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=1,in_port=1,actions=resubmit(,1)'] Exit code: 1 Stdout: '' Stderr: 'ovs-ofctl: br-tun is not a bridge or a socket\n' 2014-07-18 16:06:03.380 28794 ERROR neutron.agent.linux.ovs_lib [req-2fc4abd3-483a-4476-b14d-78c09b04368c None] Unable to execute ['ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=0,actions=drop']. Exception: Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=0,actions=drop'] Exit code: 1 Stdout: '' Stderr: 'ovs-ofctl: br-tun is not a bridge or a socket\n' When I go to look for br-tun I do 'ovs-vsctl show' and I'll *sometimes* see: ... Bridge br-tun Port br-tun Interface br-tun type: internal ... Now, this is kind of weird, but if I do "watch -n 0.5 ovs-vsctl show" I don't always see br-tun! In fact the br-tun seems to jump around a lot (sometimes its there, sometimes its listed above br-ex, sometimes below.) More info: [root@localhost ~]# ovsdb-server --version ovsdb-server (Open vSwitch) 1.11.0 Compiled Jul 30 2013 18:14:53 [root@localhost ~]# ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 1.11.0 Compiled Jul 30 2013 18:14:54 OpenFlow versions 0x1:0x1 Any help would be appreciated. -- (uberj) Jacques Uber Mozilla IT

10 years, 9 months

2
2
0 / 0

[Rdo-list] RDO Icehouse with CentOS 6.5 Openvswitch Issue

by Lakmal Warusawithana

Hi, I have tried out RDO with CentOS 6.5 following [1]. I am getting an openvswitch issue, it keep adding and deleting br-tun. my /var/log/message hitting continues message of following. Is any one com across this issue? And note, I had working setup with multi node (10 days ago), but suddenly with an yum update and re-run packstack lead to this issue. Now even allinone setup also getting this issue. Jul 24 10:22:20 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-br br-tun Jul 24 10:22:20 openstack01 kernel: device br-tun left promiscuous mode Jul 24 10:22:20 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-br br-tun Jul 24 10:22:20 openstack01 kernel: device br-tun entered promiscuous mode Jul 24 10:22:20 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-br br-tun Jul 24 10:22:20 openstack01 kernel: device br-tun left promiscuous mode Jul 24 10:22:20 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-br br-tun Jul 24 10:22:20 openstack01 kernel: device br-tun entered promiscuous mode Jul 24 10:22:21 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-br br-tun Jul 24 10:22:21 openstack01 kernel: device br-tun left promiscuous mode Jul 24 10:22:21 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-br br-tun Jul 24 10:22:21 openstack01 kernel: device br-tun entered promiscuous mode Jul 24 10:22:21 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-br br-tun Jul 24 10:22:21 openstack01 kernel: device br-tun left promiscuous mode Jul 24 10:22:21 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-br br-tun Jul 24 10:22:21 openstack01 kernel: device br-tun entered promiscuous mode Jul 24 10:22:22 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-br br-tun Jul 24 10:22:22 openstack01 kernel: device br-tun left promiscuous mode Jul 24 10:22:22 openstack01 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-br br-tun Jul 24 10:22:22 openstack01 kernel: device br-tun entered promiscuous mode [1]http://openstack.redhat.com/Neutron_with_existing_external_network -- Lakmal Warusawithana

10 years, 9 months

2
4
0 / 0

[Rdo-list] Outgoing traffic from instances! RDO icehouse with GRE fedora20

by Antonio C. Velez

Hi everyone, I'm using icehouse with GRE on fedora20 in two nodes 1 controller 1 compute, everything is working great, I can loging to ssh to the instances and ping to the internet ect. but when I try to install something with yum it says conection timeout, conecting to public servers using ramdon ports 443, 80, 22 doesn't work. Someone can give me any clue of what is wrong? ------------------ Antonio C. Velez Baez Linux Consultant Vidalinux.com RHCE, RHCI, RHCX, RHCOE Red Hat Certified Training Center Email: acvelez(a)vidalinux.com Tel: 1-787-439-2983 Skype: vidalinuxpr Twitter: @vidalinux.com Website: www.vidalinux.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

10 years, 9 months

6
11
0 / 0

Re: [Rdo-list] Icehouse MariaDB-Galera -Server problem.

by john decot

Hi, the output of uname -a is Linux virtualbox.localdomain 2.6.32-431.20.3.el6.i686 #1 SMP Thu Jun 19 19:51:30 UTC 2014 i686 i686 i386 GNU/Linux John. On Tue, Jul 22, 2014 at 6:19 AM, john decot <johndecot(a)gmail.com> wrote: > Hi, > the output of uname -a is > > Linux virtualbox.localdomain 2.6.32-431.20.3.el6.i686 #1 SMP Thu Jun 19 > 19:51:30 UTC 2014 i686 i686 i386 GNU/Linux > > John. > > > > On Mon, Jul 21, 2014 at 8:47 PM, uberj <juber(a)mozilla.com> wrote: > >> Hi John, >> >> I have seen similar symptoms (specifically the absense of >> mariadb-galera-server) when I trying to install packstack on a non x86 >> version of centos. What does 'uname -a' say? Some packages needed by >> packstack are pinned to the x86 architecture so that when you install rdo >> on something other than x86 you only will be installing the noarch packages >> and miss any architecture specific packages. >> >> >> On 07/21/2014 02:06 AM, john decot wrote: >> >> Hi, >> >> I am new to openstack. I am on the way to RDO for the installation >> of openstack. >> >> >> packstack --allinone command generates output error : cannot find >> mariadb-galera-server in repo. >> >> any help will be appreciated. >> >> >> Thank You, >> >> John. >> >> >> >> >> >> _______________________________________________ >> Rdo-list mailing listRdo-list@redhat.comhttps://www.redhat.com/mailman/listinfo/rdo-list >> >> >> -- >> (uberj) Jacques Uber >> Mozilla IT >> >> >

10 years, 9 months

2
2
0 / 0

[Rdo-list] packstack error messages

by Zhao, Xin

Hello, I am installing icehouse from RDO, on a RHEL7 VM, using packstack. Get the following error: ...... Applying 130.199.185.76_glance.pp Applying 130.199.185.76_cinder.pp 130.199.185.76_keystone.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 130.199.185.76_keystone.pp Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[_member_]: Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint http://127.0.0.1:35357/v2.0/ role-list' returned 1: 'NoneType' object has no attribute '__getitem__' You will find full trace in log /var/tmp/packstack/20140721-102751-Mviqzb/manifests/130.199.185.76_keystone.pp.log Please check log file /var/tmp/packstack/20140721-102751-Mviqzb/openstack-setup.log for more information Any idea what caused this ? I am using the rdo repo from rdo-release-icehouse-4 rpm. Thanks in advance, Xin

10 years, 9 months

2
2
0 / 0

[Rdo-list] Openshift inside Openstack ? how to access internal network from external ?

by Antonio C. Velez

I successfully install openshift origin inside openstack, but I cannot access my openshift apps from my external network! broker and node already have floating ips but the dns on broker assign internal ips for my apps! what the correct procedure to fix this issue? Thanks in advance!!! ------------------ Antonio C. Velez Baez Linux Consultant Vidalinux.com RHCE, RHCI, RHCX, RHCOE Red Hat Certified Training Center Email: acvelez(a)vidalinux.com Tel: 1-787-439-2983 Skype: vidalinuxpr Twitter: @vidalinux.com Website: www.vidalinux.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

10 years, 9 months

1
1
0 / 0

[Rdo-list] Icehouse MariaDB-Galera -Server problem.

by john decot

Hi, I am new to openstack. I am on the way to RDO for the installation of openstack. packstack --allinone command generates output error : cannot find mariadb-galera-server in repo. any help will be appreciated. Thank You, John.

10 years, 9 months

2
1
0 / 0

[Rdo-list] Quickstart should mention architecture requirements

by Lars Kellogg-Stedman

I just spent some time debugging an issue on #rdo in which someone appeared to have done everything correctly but was unable to install RDO because of several missing packages. It turns out this was because they were working with an i686 CentOS image. I think we need to update the "Prerequisites" section of the Quickstart document (http://openstack.redhat.com/Quickstart) to indicate that we only support x86_64, because otherwise this is a tricky failure mode to detect: there are no particular errors, and all the .noarch packages still show up, so the problem is not immediately obvious. -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter

10 years, 9 months

4
4
0 / 0

Re: [Rdo-list] Icehouse multi-node - Centos7 - live migration failed because of "network qbr no such device"

by Benoit ML

Hello, I know that ... I have started with ml2 plugins for this reason. Perhaps can it be a bug in ml2 plugin ? Next week i will try with ml2 and admin credential on neutron, will see. Moreover, for information, by default, puppet rdo modules from foreman configure erything with openvswitch plugin by default. Thank you. Regards, 2014-07-17 21:59 GMT+02:00 Miguel Angel <miguelangel(a)ajo.es>: > Be aware that ovs plug in deprecated, and it's going to be removed now > from Juno. This could only harm if you wanted to upgrade to Juno at a > later time. Otherwise it may be ok. > > Could you try using the admin credentials in the settings? > On Jul 17, 2014 4:54 PM, "Benoit ML" <ben42ml(a)gmail.com> wrote: > >> Hello, >> >> Evrything now works. I replace ml2 by openvswitch for the core plugin. >> >> >> ##core_plugin =neutron.plugins.ml2.plugin.Ml2Plugin >> core_plugin =openvswitch >> >> >> Regards, >> >> >> >> 2014-07-16 17:28 GMT+02:00 Benoit ML <ben42ml(a)gmail.com>: >> >>> Hello, >>> >>> Another mail about the problem.... Well i have enable debug = True in >>> keystone.conf >>> >>> And after a nova migrate <VM>, when i nova show <VM> : >>> >>> ============================================================================== >>> | fault | {"message": "Remote error: >>> Unauthorized {\"error\": {\"message\": \"User >>> 0b45ccc267e04b59911e88381bb450c0 is unauthorized for tenant services\", >>> \"code\": 401, \"title\": \"Unauthorized\"}} | >>> >>> ============================================================================== >>> >>> So well User with id 0b45ccc267e04b59911e88381bb450c0 is neutron : >>> >>> ============================================================================== >>> keystone user-list >>> | 0b45ccc267e04b59911e88381bb450c0 | neutron | True | | >>> >>> ============================================================================== >>> >>> And the role seems good : >>> >>> ============================================================================== >>> keystone user-role-add --user=neutron --tenant=services --role=admin >>> Conflict occurred attempting to store role grant. User >>> 0b45ccc267e04b59911e88381bb450c0 already has role >>> 734c2fb6fb444792b5ede1fa1e17fb7e in tenant dea82f7937064b6da1c370280d8bfdad >>> (HTTP 409) >>> >>> >>> keystone user-role-list --user neutron --tenant services >>> >>> +----------------------------------+-------+----------------------------------+----------------------------------+ >>> | id | name | >>> user_id | tenant_id | >>> >>> +----------------------------------+-------+----------------------------------+----------------------------------+ >>> | 734c2fb6fb444792b5ede1fa1e17fb7e | admin | >>> 0b45ccc267e04b59911e88381bb450c0 | dea82f7937064b6da1c370280d8bfdad | >>> >>> +----------------------------------+-------+----------------------------------+----------------------------------+ >>> >>> keystone tenant-list >>> +----------------------------------+----------+---------+ >>> | id | name | enabled | >>> +----------------------------------+----------+---------+ >>> | e250f7573010415da6f191e0b53faae5 | admin | True | >>> | fa30c6bdd56e45dea48dfbe9c3ee8782 | exploit | True | >>> | dea82f7937064b6da1c370280d8bfdad | services | True | >>> +----------------------------------+----------+---------+ >>> >>> >>> ============================================================================== >>> >>> >>> Really i didn't see where is my mistake ... can you help me plz ? >>> >>> >>> Thank you in advance ! >>> >>> Regards, >>> >>> >>> >>> >>> >>> >>> 2014-07-15 15:13 GMT+02:00 Benoit ML <ben42ml(a)gmail.com>: >>> >>> Hello again, >>>> >>>> Ok on controller node I modify the neutron server configuration with >>>> nova_admin_tenant_id = f23ed5be5f534fdba31d23f60621347d >>>> >>>> where id is "services" in keystone and now it's working with "vif_plugging_is_fatal >>>> = True". Good thing. >>>> >>>> Well by the way the migrate doesnt working ... >>>> >>>> >>>> >>>> >>>> 2014-07-15 14:20 GMT+02:00 Benoit ML <ben42ml(a)gmail.com>: >>>> >>>> Hello, >>>>> >>>>> Thank you for taking time ! >>>>> >>>>> Well on the compute node, when i activate "vif_plugging_is_fatal = >>>>> True", the vm creation stuck in spawning state, and in neutron server log i >>>>> have : >>>>> >>>>> ======================================= >>>>> 2014-07-15 14:12:52.351 18448 DEBUG neutron.notifiers.nova [-] Sending >>>>> events: [{'status': 'completed', 'tag': >>>>> u'ba56921c-4628-4fcc-9dc5-2b324cd91faf', 'name': 'network-vif-plugged', >>>>> 'server_uuid': u'f8554441-565c-49ec-bc88-3cbc628b0579'}] send_events >>>>> /usr/lib/python2.7/site-packages/neutron/notifiers/nova.py:218 >>>>> 2014-07-15 14:12:52.354 18448 INFO urllib3.connectionpool [-] Starting >>>>> new HTTP connection (1): localhost >>>>> 2014-07-15 14:12:52.360 18448 DEBUG urllib3.connectionpool [-] "POST >>>>> /v2/5c9c186a909e499e9da0dd5cf2c403e0/os-server-external-events HTTP/1.1" >>>>> 401 23 _make_request >>>>> /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:295 >>>>> 2014-07-15 14:12:52.362 18448 INFO urllib3.connectionpool [-] Starting >>>>> new HTTP connection (1): localhost >>>>> 2014-07-15 14:12:52.452 18448 DEBUG urllib3.connectionpool [-] "POST >>>>> /v2.0/tokens HTTP/1.1" 401 114 _make_request >>>>> /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:295 >>>>> 2014-07-15 14:12:52.453 18448 ERROR neutron.notifiers.nova [-] Failed >>>>> to notify nova on events: [{'status': 'completed', 'tag': >>>>> u'ba56921c-4628-4fcc-9dc5-2b324cd91faf', 'name': 'network-vif-plugged', >>>>> 'server_uuid': u'f8554441-565c-49ec-bc88-3cbc628b0579'}] >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova Traceback >>>>> (most recent call last): >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova File >>>>> "/usr/lib/python2.7/site-packages/neutron/notifiers/nova.py", line 221, in >>>>> send_events >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova >>>>> batched_events) >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova File >>>>> "/usr/lib/python2.7/site-packages/novaclient/v1_1/contrib/server_external_events.py", >>>>> line 39, in create >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova >>>>> return_raw=True) >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova File >>>>> "/usr/lib/python2.7/site-packages/novaclient/base.py", line 152, in _create >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova _resp, >>>>> body = self.api.client.post(url, body=body) >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova File >>>>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 312, in post >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova return >>>>> self._cs_request(url, 'POST', **kwargs) >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova File >>>>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 301, in >>>>> _cs_request >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova raise e >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova >>>>> Unauthorized: Unauthorized (HTTP 401) >>>>> 2014-07-15 14:12:52.453 18448 TRACE neutron.notifiers.nova >>>>> 2014-07-15 14:12:58.321 18448 DEBUG neutron.openstack.common.rpc.amqp >>>>> [-] received {u'_context_roles': [u'admin'], u'_context_request_id': >>>>> u'req-9bf35c42-3477-4ed3-8092-af729c21198c', u'_context_read_deleted': >>>>> u'no', u'_context_user_name': None, u'_context_project_name': None, >>>>> u'namespace': None, u'_context_tenant_id': None, u'args': {u'agent_state': >>>>> {u'agent_state': {u'topic': u'N/A', u'binary': >>>>> u'neutron-openvswitch-agent', u'host': u'pvidgsh006.pvi', u'agent_type': >>>>> u'Open vSwitch agent', u'configurations': {u'tunnel_types': [u'vxlan'], >>>>> u'tunneling_ip': u'192.168.40.5', u'bridge_mappings': {}, u'l2_population': >>>>> False, u'devices': 1}}}, u'time': u'2014-07-15T12:12:58.313995'}, >>>>> u'_context_tenant': None, u'_unique_id': >>>>> u'7c9a4dfcd256494caf6e1327c8051e29', u'_context_is_admin': True, >>>>> u'version': u'1.0', u'_context_timestamp': u'2014-07-15 12:01:28.190772', >>>>> u'_context_tenant_name': None, u'_context_user': None, u'_context_user_id': >>>>> None, u'method': u'report_state', u'_context_project_id': None} _safe_log >>>>> /usr/lib/python2.7/site-packages/neutron/openstack/common/rpc/common.py:280 >>>>> ======================================= >>>>> >>>>> Well I'm supposed it's related ... Perhaps with those options in >>>>> neutron.conf : >>>>> ====================================== >>>>> notify_nova_on_port_status_changes = True >>>>> notify_nova_on_port_data_changes = True >>>>> nova_url = http://localhost:8774/v2 >>>>> nova_admin_tenant_name = services >>>>> nova_admin_username = nova >>>>> nova_admin_password = nova >>>>> nova_admin_auth_url = http://localhost:35357/v2.0 >>>>> ====================================== >>>>> >>>>> But well didnt see anything wrong ... >>>>> >>>>> Thank you in advance ! >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> 2014-07-11 16:08 GMT+02:00 Vimal Kumar <vimal7370(a)gmail.com>: >>>>> >>>>> ----- >>>>>> File "/usr/lib/python2.7/site-packages/neutronclient/client.py", line >>>>>> 239, in authenticate\\n content_type="application/json")\\n\', u\' File >>>>>> "/usr/lib/python2.7/site-packages/neutronclient/client.py", line 163, in >>>>>> _cs_request\\n raise exceptions.Unauthorized(message=body)\\n\', >>>>>> u\'Unauthorized: {"error": {"message": "The request you have made requires >>>>>> authentication.", "code": 401, "title": "Unauthorized"}}\\n\'].\n'] >>>>>> ----- >>>>>> >>>>>> Looks like HTTP connection to neutron server is resulting in 401 >>>>>> error. >>>>>> >>>>>> Try enabling debug mode for neutron server and then tail >>>>>> /var/log/neutron/server.log , hopefully you should get more info. >>>>>> >>>>>> >>>>>> On Fri, Jul 11, 2014 at 7:13 PM, Benoit ML <ben42ml(a)gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Ok I see. Nova telles neutron/openvswitch to create the bridge qbr >>>>>>> prior to the migration itself. >>>>>>> I ve already activate debug and verbose ... But well i'm really >>>>>>> stuck, dont know how and where to search/look ... >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2014-07-11 15:09 GMT+02:00 Miguel Angel <miguelangel(a)ajo.es>: >>>>>>> >>>>>>> Hi Benoit, >>>>>>>> >>>>>>>> A manual virsh migration should fail, because the >>>>>>>> network ports are not migrated to the destination host. >>>>>>>> >>>>>>>> You must investigate on the authentication problem itself, >>>>>>>> and let nova handle all the underlying API calls which should >>>>>>>> happen... >>>>>>>> >>>>>>>> May be it's worth setting nova.conf to debug=True >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> irc: ajo / mangelajo >>>>>>>> Miguel Angel Ajo Pelayo >>>>>>>> +34 636 52 25 69 >>>>>>>> skype: ajoajoajo >>>>>>>> >>>>>>>> >>>>>>>> 2014-07-11 14:41 GMT+02:00 Benoit ML <ben42ml(a)gmail.com>: >>>>>>>> >>>>>>>> Hello, >>>>>>>>> >>>>>>>>> cat /etc/redhat-release >>>>>>>>> CentOS Linux release 7 (Rebuilt from: RHEL 7.0) >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> 2014-07-11 13:40 GMT+02:00 Boris Derzhavets < >>>>>>>>> bderzhavets(a)hotmail.com>: >>>>>>>>> >>>>>>>>> Could you please post /etc/redhat-release. >>>>>>>>>> >>>>>>>>>> Boris. >>>>>>>>>> >>>>>>>>>> ------------------------------ >>>>>>>>>> Date: Fri, 11 Jul 2014 11:57:12 +0200 >>>>>>>>>> From: ben42ml(a)gmail.com >>>>>>>>>> To: rdo-list(a)redhat.com >>>>>>>>>> Subject: [Rdo-list] Icehouse multi-node - Centos7 - live >>>>>>>>>> migration failed because of "network qbr no such device" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I'm working on a multi-node setup of openstack Icehouse using >>>>>>>>>> centos7. >>>>>>>>>> Well i have : >>>>>>>>>> - one controllor node with all server services thing stuff >>>>>>>>>> - one network node with openvswitch agent, l3-agent, dhcp-agent >>>>>>>>>> - two compute node with nova-compute and neutron-openvswitch >>>>>>>>>> - one storage nfs node >>>>>>>>>> >>>>>>>>>> NetworkManager is deleted on compute nodes and network node. >>>>>>>>>> >>>>>>>>>> My network use is configured to use vxlan. I can create VM, >>>>>>>>>> tenant-network, external-network, routeur, assign floating-ip to VM, push >>>>>>>>>> ssh-key into VM, create volume from glance image, etc... Evrything is >>>>>>>>>> conected and reacheable. Pretty cool :) >>>>>>>>>> >>>>>>>>>> But when i try to migrate VM things go wrong ... I have >>>>>>>>>> configured nova, libvirtd and qemu to use migration through libvirt-tcp. >>>>>>>>>> I have create and exchanged ssh-key for nova user on all node. I >>>>>>>>>> have verified userid and groupid of nova. >>>>>>>>>> >>>>>>>>>> Well nova-compute log, on the target compute node, : >>>>>>>>>> 2014-07-11 11:45:02.749 6984 TRACE nova.compute.manager >>>>>>>>>> [instance: a5326fe1-4faa-4347-ba29-159fce26a85c] RemoteError: Remote error: >>>>>>>>>> Unauthorized {"error": {"m >>>>>>>>>> essage": "The request you have made requires authentication.", >>>>>>>>>> "code": 401, "title": "Unauthorized"}} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So well after searching a lots in all logs, i have fount that i >>>>>>>>>> cant simply migration VM between compute node with a simple virsh : >>>>>>>>>> virsh migrate instance-00000084 qemu+tcp://<dest>/system >>>>>>>>>> >>>>>>>>>> The error is : >>>>>>>>>> erreur :Cannot get interface MTU on 'qbr3ca65809-05': No such >>>>>>>>>> device >>>>>>>>>> >>>>>>>>>> Well when i look on the source hyperviseur the bridge >>>>>>>>>> "qbr3ca65809" exists and have a network tap device. And moreover i >>>>>>>>>> manually create qbr3ca65809 on the target hypervisor, virsh migrate succed ! >>>>>>>>>> >>>>>>>>>> Can you help me plz ? >>>>>>>>>> What can i do wrong ? Perhpas neutron must create the bridge >>>>>>>>>> before migration but didnt for a mis configuration ? >>>>>>>>>> >>>>>>>>>> Plz ask anything you need ! >>>>>>>>>> >>>>>>>>>> Thank you in advance. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The full nova-compute log attached. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> Benoit >>>>>>>>>> >>>>>>>>>> _______________________________________________ Rdo-list mailing >>>>>>>>>> list Rdo-list(a)redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> Benoit >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rdo-list mailing list >>>>>>>>> Rdo-list(a)redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Benoit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rdo-list mailing list >>>>>>> Rdo-list(a)redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Benoit >>>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> Benoit >>>> >>> >>> >>> >>> -- >>> -- >>> Benoit >>> >> >> >> >> -- >> -- >> Benoit >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> -- -- Benoit

10 years, 9 months

1
0
0 / 0

[Rdo-list] Icehouse multi-node - Centos7 - live migration failed because of "network qbr no such device"

by Benoit ML

Hello, I'm working on a multi-node setup of openstack Icehouse using centos7. Well i have : - one controllor node with all server services thing stuff - one network node with openvswitch agent, l3-agent, dhcp-agent - two compute node with nova-compute and neutron-openvswitch - one storage nfs node NetworkManager is deleted on compute nodes and network node. My network use is configured to use vxlan. I can create VM, tenant-network, external-network, routeur, assign floating-ip to VM, push ssh-key into VM, create volume from glance image, etc... Evrything is conected and reacheable. Pretty cool :) But when i try to migrate VM things go wrong ... I have configured nova, libvirtd and qemu to use migration through libvirt-tcp. I have create and exchanged ssh-key for nova user on all node. I have verified userid and groupid of nova. Well nova-compute log, on the target compute node, : 2014-07-11 11:45:02.749 6984 TRACE nova.compute.manager [instance: a5326fe1-4faa-4347-ba29-159fce26a85c] RemoteError: Remote error: Unauthorized {"error": {"m essage": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} So well after searching a lots in all logs, i have fount that i cant simply migration VM between compute node with a simple virsh : virsh migrate instance-00000084 qemu+tcp://<dest>/system The error is : erreur :Cannot get interface MTU on 'qbr3ca65809-05': No such device Well when i look on the source hyperviseur the bridge "qbr3ca65809" exists and have a network tap device. And moreover i manually create qbr3ca65809 on the target hypervisor, virsh migrate succed ! Can you help me plz ? What can i do wrong ? Perhpas neutron must create the bridge before migration but didnt for a mis configuration ? Plz ask anything you need ! Thank you in advance. The full nova-compute log attached. Regards, -- -- Benoit

10 years, 9 months

4
11
0 / 0

Re: [Rdo-list] Icehouse Neutron DB code bug still persists?

by Kodiak Firesmith

Ihar, Apologies! I looked at this with fresh eyes this morning and realized that while neutron-server was listening on 9696 I hadn't yet put a rule into our enterprise iptables management module in Puppet for neutron-server yet, thus Neutron stuff was timing out when a user attempts to log into Horizon. Everything works well now - I'll make sure to pay the help forward by filing an Openstack documentation bug request that distils the missing steps that the RDO team helped me get through yesterday. Thanks so much! - Kodiak Date: Thu, 17 Jul 2014 10:55:08 +0200 From: Ihar Hrachyshka <ihrachys(a)redhat.com> To: rdo-list(a)redhat.com Subject: Re: [Rdo-list] Icehouse Neutron DB code bug still persists? Message-ID: <53C78F6C.3070106(a)redhat.com> Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/07/14 18:58, Kodiak Firesmith wrote: > Of course setting up Neutron has taken Horizon offline: > > http://paste.openstack.org/show/86778/ > Any interesting log messages for neutron service? Do basic neutron requests like 'neutron net-list' work? > > - Kodiak > > On Wed, Jul 16, 2014 at 12:34 PM, Kodiak Firesmith > <kfiresmith(a)gmail.com> wrote: >> Further modifying /etc/neutron/neutron.conf as follows allowed >> the neutron-db-manage goodness to happen: >> >> -service_plugins = router +service_plugins = >> neutron.services.l3_router.l3_ router_plugin.L3RouterPlugin >> >> # neutron-db-manage --config-file /etc/neutron/neutron.conf >> --config-file /etc/neutron/plugin.ini upgrade head No handlers >> could be found for logger "neutron.common.legacy" INFO >> [alembic.migration] Context impl MySQLImpl. INFO >> [alembic.migration] Will assume non-transactional DDL. INFO >> [alembic.migration] Running upgrade None -> folsom INFO >> [alembic.migration] Running upgrade folsom -> 2c4af419145b ... >> INFO [alembic.migration] Running upgrade 1341ed32cc1e -> >> grizzly INFO [alembic.migration] Running upgrade grizzly -> >> f489cf14a79c INFO [alembic.migration] Running upgrade >> f489cf14a79c -> 176a85fc7d79 ... INFO [alembic.migration] >> Running upgrade 49f5e553f61f -> 40b0aff0302e INFO >> [alembic.migration] Running upgrade 40b0aff0302e -> havana INFO >> [alembic.migration] Running upgrade havana -> e197124d4b9 ... >> INFO [alembic.migration] Running upgrade 538732fa21e1 -> >> 5ac1c354a051 INFO [alembic.migration] Running upgrade >> 5ac1c354a051 -> icehouse >> >> I am now cautiously optimistic that I'm back on track - will >> report back with success fail. If success I'll submit a >> documentation bug to the docs.openstack people. >> >> Here's my tables now: http://paste.openstack.org/show/86776/ >> >> Thanks a million! >> >> - Kodiak >> >> On Wed, Jul 16, 2014 at 11:15 AM, Kodiak Firesmith >> <kfiresmith(a)gmail.com> wrote: >>> Thanks again Kuba! >>> >>> So I think it's gotten farther. I replaced the line on >>> /etc/neutron/neutron.conf: >>> >>> -core_plugin = ml2 +core_plugin = neutron.plugins.ml2.plugin. >>> Ml2Plugin >>> >>> Then I re-ran the neutron-db-manage as seen in the paste below. >>> It's gotten past ml2 and now is erroring out on 'router': >>> >>> http://paste.openstack.org/show/86759/ >>> >>> >>> - Kodiak >>> >>> On Wed, Jul 16, 2014 at 11:01 AM, Jakub Libosvar >>> <libosvar(a)redhat.com> wrote: >>>> On 07/16/2014 04:57 PM, Kodiak Firesmith wrote: >>>>> Hello Kuba, Thanks for the reply. I used the ml2 ini file >>>>> as my core plugin per the docs and did what you mentioned. >>>>> It resulted in a traceback unfortunately. >>>>> >>>>> Here is a specific accounting of what I did: >>>>> http://paste.openstack.org/show/86756/ >>>> >>>> Ah, this is because we don't load full path from entry_points >>>> for plugins in neutron-db-manage (we didn't fix this because >>>> this dependency is going to be removed soon). >>>> >>>> Can you please try to change core_plugin in neutron.conf to >>>> >>>> core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin >>>> >>>> and re-run neutron-db-manage. >>>> >>>> Thanks, Kuba >>>>> >>>>> So it looks like maybe there is an issue with the ml2 >>>>> plugin as the openstack docs cover it so far as how it >>>>> works with the RDO packages. >>>>> >>>>> Another admin reports that stuff "just works" in RDO >>>>> packstack - maybe there is some workaround in Packstack or >>>>> maybe it uses another driver and not ML2? >>>>> >>>>> Thanks again, - Kodiak >>>>> >>>>> On Wed, Jul 16, 2014 at 8:54 AM, Jakub Libosvar >>>>> <libosvar(a)redhat.com> wrote: >>>>>> On 07/16/2014 02:25 PM, Kodiak Firesmith wrote: >>>>>>> Hello, First go-round with Openstack and first post on >>>>>>> the list so bear with me... >>>>>>> >>>>>>> I've been working through the manual installation of >>>>>>> RDO using the docs.openstack installation guide. >>>>>>> Everything went smoothly for the most part until >>>>>>> Neutron. It appears I've been hit by the same bug(?) >>>>>>> discussed here: >>>>>>> http://www.marshut.com/ithyup/net-create-issue.html#ithzts, >>>>>>> and here: >>>>>>> https://www.redhat.com/archives/rdo-list/2014-March/msg00005.html >>>>>>> >>>>>>> ...among other places. >>>>>>> >>>>>>> Upon first launch of the neutron-server daemon, this >>>>>>> appears in the neutron-server log file: >>>>>>> http://paste.openstack.org/show/86614/ >>>>>>> >>>>>>> And once you go into the db you can see that a bunch of >>>>>>> tables are not created that should be. >>>>>>> >>>>>>> As the first link alludes to, it looks like a MyISAM / >>>>>>> InnoDB formatting mix-up but I'm no MySQL guy so I >>>>>>> can't prove that. >>>>>>> >>>>>>> I would really like if someone on the list who is a bit >>>>>>> more experienced with this stuff could please see if >>>>>>> the suspicions raised in the links above are correct, >>>>>>> and if so, could the RDO people please provide a >>>>>>> workaround to get me back up and running with our test >>>>>>> deployment? >>>>>>> >>>>>>> Thanks! - Kodiak >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rdo-list mailing list Rdo-list(a)redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>>>>> >>>>>> Hi Kodiak, >>>>>> >>>>>> I think there is a bug in documentation, I'm missing >>>>>> running neutron-db-manage command to create scheme for >>>>>> neutron. Can you please try to 1. stop neutron-server 2. >>>>>> create a new database 3. set connection string in >>>>>> neutron.conf 4. run neutron-db-manage --config-file >>>>>> /etc/neutron/neutron.conf --config-file >>>>>> <path_to_your_core_plugin_file.ini> upgrade head 5. start >>>>>> neutron-server >>>>>> >>>>>> Kuba >>>> > > _______________________________________________ Rdo-list mailing > list Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTx49sAAoJEC5aWaUY1u577IoH/A8xk9HwDgJYJ6M2T11D3Yt+ VkRyZvR8drsVl2GaX51uQF4F9HWNgT6zhZqk4Y9n8MvTtG66XIUI7K0KW51uU05/ Ki4NaD9RrkVMIvNGExCSOzcpuUaCYmTOjDVoHkKT+jp+vdRcjNrFZHtI7IE1qGpI BSbhNzV8htJJiFI40dsjJgZgutmqORvU79oFZDADcUMQnb/tIH9hw5xSAWe2+dzi IzUq88Brd90t8tteAAauNaHYcx4yG9dGZ7xaXi0FNqOhw/WzaVm8U/UkKmvEatoV NBlnbliuPBBtttGr/EtOtUcyo9eiNN1P+IvmoJgz8dSvbX95vAXZBGA+2Nq/ecQ= =dPVj -----END PGP SIGNATURE-----

10 years, 9 months

1
1
0 / 0

[Rdo-list] Icehouse Neutron DB code bug still persists?

by Kodiak Firesmith

Hello, First go-round with Openstack and first post on the list so bear with me... I've been working through the manual installation of RDO using the docs.openstack installation guide. Everything went smoothly for the most part until Neutron. It appears I've been hit by the same bug(?) discussed here: http://www.marshut.com/ithyup/net-create-issue.html#ithzts, and here: https://www.redhat.com/archives/rdo-list/2014-March/msg00005.html ...among other places. Upon first launch of the neutron-server daemon, this appears in the neutron-server log file: http://paste.openstack.org/show/86614/ And once you go into the db you can see that a bunch of tables are not created that should be. As the first link alludes to, it looks like a MyISAM / InnoDB formatting mix-up but I'm no MySQL guy so I can't prove that. I would really like if someone on the list who is a bit more experienced with this stuff could please see if the suspicions raised in the links above are correct, and if so, could the RDO people please provide a workaround to get me back up and running with our test deployment? Thanks! - Kodiak

10 years, 9 months

4
8
0 / 0

Re: [Rdo-list] cinder doesn't find volgroup/cinder-volumes

by Nathan M.

> > Are you able to reproduce this issue (assuming you > can consistently) on current latest IceHouse RDO packages? You haven't > noted the versions you're using. rpm -qa | grep icehouse rdo-release-icehouse-4.noarch Maybe you don't really have enough free space there? I don't have a > Cinder setup to do a sanity check, you might want to ensure if you have > your Cinder filter scheduler configured correctly. I created another vg and gave it 30 gigs just in case: [root@node1]/etc/cinder# (openstack_admin)] vgdisplay cinder-volumes --- Volume group --- VG Name cinder-volumes System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 30.00 GiB PE Size 4.00 MiB Total PE 7679 Alloc PE / Size 0 / 0 Free PE / Size 7679 / 30.00 GiB VG UUID huXkqD-3JIm-Fasr-Gkwc-EPVP-n15c-KIvBRc > > 2014-07-11 12:34:43.325 8665 ERROR cinder.scheduler.flows.create_volume > > [req-2acb85f1-5b7b-4b63-bf95-9037338cb52b > 555e3e826c9f445c9975d0e1c6e00fc6 > > ff6a2b534e984db58313ae194b2d908c - - -] Failed to schedule_create_volume: > > No valid host was found. > > 2014-07-11 12:35:16.253 8665 WARNING cinder.context [-] Arguments dropped > > when creating context: {'user': None, 'tenant': None, 'user_identity': > u'- > > - - - -'} > > > > -- > /kashyap >

10 years, 9 months

2
2
0 / 0

Re: [Rdo-list] Glance/Keystone problem

by Adam Huffman

Hi Flavio, Thanks for looking. In the end, the cause here was an omission in the api-paste file for Keystone, now fixed. Best Wishes, Adam On Wed, Jul 16, 2014 at 5:35 PM, Adam Huffman <adam.huffman(a)gmail.com> wrote: > Hi Flavio, > > Thanks for looking. In the end, the cause here was an omission in the > api-paste file for Keystone, now fixed. > > Best Wishes, > Adam > > On Wed, Jul 16, 2014 at 9:11 AM, Flavio Percoco <flavio(a)redhat.com> wrote: >> On 07/15/2014 03:32 PM, Adam Huffman wrote: >>> I've altered Keystone on my Icehouse cloud to use Apache/mod_ssl. The >>> Keystone and Nova clients are working (more or less) but I'm having >>> trouble with Glance. >> >> Hi Adam, >> >> We'd need your config files to have a better idea of what the issue >> could be. Based on the logs you just sent, keystone's middleware can't >> find/load the certification file: >> >> "Unable to load certificate. Ensure your system is configured properly" >> >> Some things you could check: >> >> 1. Is the file path in your config file correct? >> 2. Is the config option name correct? >> 3. Is the file readable? >> >> Hope the above helps, >> Flavio >> >> >>> >>> Here's an example of the sort of error I'm seeing from the Glance api.log: >>> >>> >>> 2014-07-15 14:24:00.551 24063 DEBUG >>> glance.api.middleware.version_negotiation [-] Determining version of >>> request: GET /v1/shared-images/e35356df747b4c5aa663fae2897facba >>> Accept: process_request >>> /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:44 >>> 2014-07-15 14:24:00.552 24063 DEBUG >>> glance.api.middleware.version_negotiation [-] Using url versioning >>> process_request >>> /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:57 >>> 2014-07-15 14:24:00.552 24063 DEBUG >>> glance.api.middleware.version_negotiation [-] Matched version: v1 >>> process_request >>> /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:69 >>> 2014-07-15 14:24:00.552 24063 DEBUG >>> glance.api.middleware.version_negotiation [-] new path >>> /v1/shared-images/e35356df747b4c5aa663fae2897facba process_request >>> /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:70 >>> 2014-07-15 14:24:00.553 24063 DEBUG >>> keystoneclient.middleware.auth_token [-] Authenticating user token >>> __call__ /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:666 >>> 2014-07-15 14:24:00.553 24063 DEBUG >>> keystoneclient.middleware.auth_token [-] Removing headers from request >>> environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role >>> _remove_auth_headers >>> /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:725 >>> 2014-07-15 14:24:00.591 24063 INFO urllib3.connectionpool [-] Starting >>> new HTTPS connection (1): <hostname> >>> 2014-07-15 14:24:01.921 24063 DEBUG urllib3.connectionpool [-] "POST >>> /v2.0/tokens HTTP/1.1" 200 7003 _make_request >>> /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 >>> 2014-07-15 14:24:01.931 24063 INFO urllib3.connectionpool [-] Starting >>> new HTTPS connection (1): <hostname> >>> 2014-07-15 14:24:03.243 24063 DEBUG urllib3.connectionpool [-] "GET >>> /v2.0/tokens/revoked HTTP/1.1" 200 682 _make_request >>> /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 >>> 2014-07-15 14:24:03.252 24063 INFO urllib3.connectionpool [-] Starting >>> new HTTPS connection (1): <hostname> >>> 2014-07-15 14:24:04.529 24063 DEBUG urllib3.connectionpool [-] "GET / >>> HTTP/1.1" 300 384 _make_request >>> /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 >>> 2014-07-15 14:24:04.530 24063 DEBUG >>> keystoneclient.middleware.auth_token [-] Server reports support for >>> api versions: v3.0 _get_supported_versions >>> /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:656 >>> 2014-07-15 14:24:04.531 24063 INFO >>> keystoneclient.middleware.auth_token [-] Auth Token confirmed use of >>> v3.0 apis >>> 2014-07-15 14:24:04.531 24063 INFO urllib3.connectionpool [-] Starting >>> new HTTPS connection (1): <hostname> >>> 2014-07-15 14:24:04.667 24063 DEBUG urllib3.connectionpool [-] "GET >>> /v3/OS-SIMPLE-CERT/certificates HTTP/1.1" 404 93 _make_request >>> /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 >>> 2014-07-15 14:24:04.669 24063 DEBUG >>> keystoneclient.middleware.auth_token [-] Token validation failure. >>> _validate_user_token >>> /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:943 >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token Traceback (most recent call >>> last): >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 930, in _validate_user_token >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token verified = >>> self.verify_signed_token(user_token, token_ids) >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1347, in verify_signed_token >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token if >>> self.is_signed_token_revoked(token_ids): >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1299, in is_signed_token_revoked >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token if >>> self._is_token_id_in_revoked_list(token_id): >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1306, in _is_token_id_in_revoked_list >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token revocation_list = >>> self.token_revocation_list >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1413, in token_revocation_list >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token self.token_revocation_list = >>> self.fetch_revocation_list() >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1459, in fetch_revocation_list >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token return >>> self.cms_verify(data['signed']) >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1333, in cms_verify >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token self.fetch_signing_cert() >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1477, in fetch_signing_cert >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token >>> self._fetch_cert_file(self.signing_cert_file_name, 'signing') >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token File >>> "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", >>> line 1473, in _fetch_cert_file >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token raise >>> exceptions.CertificateConfigError(response.text) >>> 2014-07-15 14:24:04.669 24063 TRACE >>> keystoneclient.middleware.auth_token CertificateConfigError: Unable to >>> load certificate. Ensure your system is configured properly. >>> 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token >>> 2014-07-15 14:24:04.671 24063 DEBUG >>> keystoneclient.middleware.auth_token [-] Marking token as unauthorized >>> in cache _cache_store_invalid >>> /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:1239 >>> 2014-07-15 14:24:04.672 24063 WARNING >>> keystoneclient.middleware.auth_token [-] Authorization failed for >>> token >>> 2014-07-15 14:24:04.672 24063 INFO >>> keystoneclient.middleware.auth_token [-] Invalid user token - >>> deferring reject downstream >>> 2014-07-15 14:24:04.674 24063 INFO glance.wsgi.server [-] <IP address> >>> - - [15/Jul/2014 14:24:04] "GET >>> /v1/shared-images/e35356df747b4c5aa663fae2897facba HTTP/1.1" 401 381 >>> 4.124231 >>> >>> There is a bug report about a race condition involving Cinder, but >>> that was supposed to have been fixed. >>> >>> Any suggestions appreciated. >>> >>> Best Wishes, >>> Adam >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >> >> >> -- >> @flaper87 >> Flavio Percoco >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list

10 years, 9 months

1
0
0 / 0

[Rdo-list] Glance/Keystone problem

by Adam Huffman

I've altered Keystone on my Icehouse cloud to use Apache/mod_ssl. The Keystone and Nova clients are working (more or less) but I'm having trouble with Glance. Here's an example of the sort of error I'm seeing from the Glance api.log: 2014-07-15 14:24:00.551 24063 DEBUG glance.api.middleware.version_negotiation [-] Determining version of request: GET /v1/shared-images/e35356df747b4c5aa663fae2897facba Accept: process_request /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:44 2014-07-15 14:24:00.552 24063 DEBUG glance.api.middleware.version_negotiation [-] Using url versioning process_request /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:57 2014-07-15 14:24:00.552 24063 DEBUG glance.api.middleware.version_negotiation [-] Matched version: v1 process_request /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:69 2014-07-15 14:24:00.552 24063 DEBUG glance.api.middleware.version_negotiation [-] new path /v1/shared-images/e35356df747b4c5aa663fae2897facba process_request /usr/lib/python2.6/site-packages/glance/api/middleware/version_negotiation.py:70 2014-07-15 14:24:00.553 24063 DEBUG keystoneclient.middleware.auth_token [-] Authenticating user token __call__ /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:666 2014-07-15 14:24:00.553 24063 DEBUG keystoneclient.middleware.auth_token [-] Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role _remove_auth_headers /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:725 2014-07-15 14:24:00.591 24063 INFO urllib3.connectionpool [-] Starting new HTTPS connection (1): <hostname> 2014-07-15 14:24:01.921 24063 DEBUG urllib3.connectionpool [-] "POST /v2.0/tokens HTTP/1.1" 200 7003 _make_request /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 2014-07-15 14:24:01.931 24063 INFO urllib3.connectionpool [-] Starting new HTTPS connection (1): <hostname> 2014-07-15 14:24:03.243 24063 DEBUG urllib3.connectionpool [-] "GET /v2.0/tokens/revoked HTTP/1.1" 200 682 _make_request /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 2014-07-15 14:24:03.252 24063 INFO urllib3.connectionpool [-] Starting new HTTPS connection (1): <hostname> 2014-07-15 14:24:04.529 24063 DEBUG urllib3.connectionpool [-] "GET / HTTP/1.1" 300 384 _make_request /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 2014-07-15 14:24:04.530 24063 DEBUG keystoneclient.middleware.auth_token [-] Server reports support for api versions: v3.0 _get_supported_versions /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:656 2014-07-15 14:24:04.531 24063 INFO keystoneclient.middleware.auth_token [-] Auth Token confirmed use of v3.0 apis 2014-07-15 14:24:04.531 24063 INFO urllib3.connectionpool [-] Starting new HTTPS connection (1): <hostname> 2014-07-15 14:24:04.667 24063 DEBUG urllib3.connectionpool [-] "GET /v3/OS-SIMPLE-CERT/certificates HTTP/1.1" 404 93 _make_request /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295 2014-07-15 14:24:04.669 24063 DEBUG keystoneclient.middleware.auth_token [-] Token validation failure. _validate_user_token /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:943 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token Traceback (most recent call last): 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 930, in _validate_user_token 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token verified = self.verify_signed_token(user_token, token_ids) 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1347, in verify_signed_token 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token if self.is_signed_token_revoked(token_ids): 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1299, in is_signed_token_revoked 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token if self._is_token_id_in_revoked_list(token_id): 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1306, in _is_token_id_in_revoked_list 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token revocation_list = self.token_revocation_list 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1413, in token_revocation_list 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token self.token_revocation_list = self.fetch_revocation_list() 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1459, in fetch_revocation_list 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token return self.cms_verify(data['signed']) 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1333, in cms_verify 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token self.fetch_signing_cert() 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1477, in fetch_signing_cert 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token self._fetch_cert_file(self.signing_cert_file_name, 'signing') 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1473, in _fetch_cert_file 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token raise exceptions.CertificateConfigError(response.text) 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token CertificateConfigError: Unable to load certificate. Ensure your system is configured properly. 2014-07-15 14:24:04.669 24063 TRACE keystoneclient.middleware.auth_token 2014-07-15 14:24:04.671 24063 DEBUG keystoneclient.middleware.auth_token [-] Marking token as unauthorized in cache _cache_store_invalid /usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:1239 2014-07-15 14:24:04.672 24063 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token 2014-07-15 14:24:04.672 24063 INFO keystoneclient.middleware.auth_token [-] Invalid user token - deferring reject downstream 2014-07-15 14:24:04.674 24063 INFO glance.wsgi.server [-] <IP address> - - [15/Jul/2014 14:24:04] "GET /v1/shared-images/e35356df747b4c5aa663fae2897facba HTTP/1.1" 401 381 4.124231 There is a bug report about a race condition involving Cinder, but that was supposed to have been fixed. Any suggestions appreciated. Best Wishes, Adam

10 years, 9 months

2
1
0 / 0

[Rdo-list] (no subject)

by Nathan M.

So I've tried to setup a local controller node and run into a problem with getting cinder to create a volume, first up the service can't find a place to drop the volume I create. If I disable and reenable the service, it shows as up - so I'm not sure how to proceed on this. I'll note nothing ever shows up in /etc/cinder/volumes Thanks in advance for any help gents/gals --Nathan [root@node1 cinder(openstack_admin)]# cinder service-list +------------------+------------------+------+---------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +------------------+------------------+------+---------+-------+----------------------------+-----------------+ | cinder-scheduler | node1.local | nova | enabled | up | 2014-07-11T19:29:45.000000 | None | | cinder-volume | node1.local@ | nova | enabled | up | 2014-07-11T19:29:46.000000 | None | | cinder-volume | node1.local@lvm1 | nova | enabled | down | 2014-07-11T19:28:51.000000 | None | +------------------+------------------+------+---------+-------+----------------------------+-----------------+ [root@node1 cinder(openstack_admin)]# openstack-status == Nova services == openstack-nova-api: active openstack-nova-cert: active openstack-nova-compute: dead (disabled on boot) openstack-nova-network: dead (disabled on boot) openstack-nova-scheduler: active openstack-nova-conductor: active == Glance services == openstack-glance-api: active openstack-glance-registry: active == Keystone service == openstack-keystone: active == Horizon service == openstack-dashboard: active == neutron services == neutron-server: active neutron-dhcp-agent: inactive (disabled on boot) neutron-l3-agent: inactive (disabled on boot) neutron-metadata-agent: inactive (disabled on boot) neutron-lbaas-agent: inactive (disabled on boot) neutron-openvswitch-agent: inactive (disabled on boot) == Swift services == openstack-swift-proxy: active openstack-swift-account: dead (disabled on boot) openstack-swift-container: dead (disabled on boot) openstack-swift-object: dead (disabled on boot) == Cinder services == openstack-cinder-api: active openstack-cinder-scheduler: active openstack-cinder-volume: active openstack-cinder-backup: inactive (disabled on boot) == Ceilometer services == openstack-ceilometer-api: active openstack-ceilometer-central: active openstack-ceilometer-compute: dead (disabled on boot) openstack-ceilometer-collector: active == Heat services == openstack-heat-api: active openstack-heat-api-cfn: active openstack-heat-api-cloudwatch: inactive (disabled on boot) openstack-heat-engine: active == Support services == openvswitch: dead (disabled on boot) messagebus: active tgtd: active rabbitmq-server: active memcached: active == Keystone users == +----------------------------------+------------+---------+----------------------+ | id | name | enabled | email | +----------------------------------+------------+---------+----------------------+ | 555e3e826c9f445c9975d0e1c6e00fc6 | admin | True | admin@local | | 4cbb547624004bbeb650d9f73875c1a2 | ceilometer | True | ceilometer@localhost | | 492d8baa1ae94e8dbf503187b5ccd0a9 | cinder | True | cinder@localhost | | fdcac23cb0bc4cd08712722b213d2e93 | glance | True | glance@localhost | | fc0d0960be5b4714b37f969fbc48d9e4 | heat | True | heat@localhost | | 48a6c949564d4e96b465fe670c92015c | heat-cfn | True | heat-cfn@localhost | | 1c531b23585e4cefb7fff7659cded687 | neutron | True | neutron@localhost | | 6ede5eb09ca64cdb934f6c92b20ba3b3 | nova | True | nova@localhost | | 6ba7e665409e4ee883e29e6def759255 | swift | True | swift@localhost | +----------------------------------+------------+---------+----------------------+ == Glance images == +--------------------------------------+--------+-------------+------------------+-----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+--------+-------------+------------------+-----------+--------+ | 6019cfa8-ee46-4617-8b56-ae5dc82013a3 | cirros | qcow2 | bare | 237896192 | active | +--------------------------------------+--------+-------------+------------------+-----------+--------+ == Nova managed services == +------------------+-------------+----------+---------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +------------------+-------------+----------+---------+-------+----------------------------+-----------------+ | nova-consoleauth | node1.local | internal | enabled | up | 2014-07-11T19:31:14.000000 | - | | nova-scheduler | node1.local | internal | enabled | up | 2014-07-11T19:31:15.000000 | - | | nova-conductor | node1.local | internal | enabled | up | 2014-07-11T19:31:14.000000 | - | | nova-cert | node1.local | internal | enabled | up | 2014-07-11T19:31:15.000000 | - | +------------------+-------------+----------+---------+-------+----------------------------+-----------------+ == Nova networks == +--------------------------------------+-------+------+ | ID | Label | Cidr | +--------------------------------------+-------+------+ | 9295ee23-c93b-43f6-801e-51d67e66313f | net1 | - | +--------------------------------------+-------+------+ == Nova instance flavors == +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True | | 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | | 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | | 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | | 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ == Nova instances == +----+------+--------+------------+-------------+----------+ | ID | Name | Status | Task State | Power State | Networks | +----+------+--------+------------+-------------+----------+ +----+------+--------+------------+-------------+----------+ [root@node1 cinder(openstack_admin)]# nova volume-create --volume-type lvm --availability-zone nova 1 +---------------------+--------------------------------------+ | Property | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | created_at | 2014-07-11T19:34:43.064107 | | display_description | - | | display_name | - | | encrypted | False | | id | 17959681-7b63-4dd2-b856-083aef246fd9 | | metadata | {} | | size | 1 | | snapshot_id | - | | source_volid | - | | status | creating | | volume_type | lvm | +---------------------+--------------------------------------+ [root@node1 cinder(openstack_admin)]# tail -5 scheduler.log 2014-07-11 12:34:43.200 8665 WARNING cinder.context [-] Arguments dropped when creating context: {'user': u'555e3e826c9f445c9975d0e1c6e00fc6', 'tenant': u'ff6a2b534e984db58313ae194b2d908c', 'user_identity': u'555e3e826c9f445c9975d0e1c6e00fc6 ff6a2b534e984db58313ae194b2d908c - - -'} 2014-07-11 12:34:43.275 8665 ERROR cinder.scheduler.filters.capacity_filter [req-2acb85f1-5b7b-4b63-bf95-9037338cb52b 555e3e826c9f445c9975d0e1c6e00fc6 ff6a2b534e984db58313ae194b2d908c - - -] Free capacity not set: volume node info collection broken. 2014-07-11 12:34:43.275 8665 WARNING cinder.scheduler.filters.capacity_filter [req-2acb85f1-5b7b-4b63-bf95-9037338cb52b 555e3e826c9f445c9975d0e1c6e00fc6 ff6a2b534e984db58313ae194b2d908c - - -] Insufficient free space for volume creation (requested / avail): 1/0.0 2014-07-11 12:34:43.325 8665 ERROR cinder.scheduler.flows.create_volume [req-2acb85f1-5b7b-4b63-bf95-9037338cb52b 555e3e826c9f445c9975d0e1c6e00fc6 ff6a2b534e984db58313ae194b2d908c - - -] Failed to schedule_create_volume: No valid host was found. 2014-07-11 12:35:16.253 8665 WARNING cinder.context [-] Arguments dropped when creating context: {'user': None, 'tenant': None, 'user_identity': u'- - - - -'} [root@node1 cinder(openstack_admin)]# cinder service-disable node1.local@lvm1 cinder-volume +------------------+---------------+----------+ | Host | Binary | Status | +------------------+---------------+----------+ | node1.local@lvm1 | cinder-volume | disabled | +------------------+---------------+----------+ [root@node1 cinder(openstack_admin)]# cinder service-enable node1.local@lvm1 cinder-volume +------------------+---------------+---------+ | Host | Binary | Status | +------------------+---------------+---------+ | node1.local@lvm1 | cinder-volume | enabled | +------------------+---------------+---------+ [root@node1 cinder(openstack_admin)]# cinder service-list +------------------+------------------+------+---------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +------------------+------------------+------+---------+-------+----------------------------+-----------------+ | cinder-scheduler | node1.local | nova | enabled | up | 2014-07-11T19:36:29.000000 | None | | cinder-volume | node1.local@ | nova | enabled | up | 2014-07-11T19:36:30.000000 | None | | cinder-volume | node1.local@lvm1 | nova | enabled | up | 2014-07-11T19:36:35.000000 | None | +------------------+------------------+------+---------+-------+----------------------------+-----------------+ [root@node1 cinder(openstack_admin)]# sed -e '/^#/d' -e '/^$/d' /etc/cinder/cinder.conf [DEFAULT] amqp_durable_queues=False rabbit_host=localhost rabbit_port=5672 rabbit_hosts=localhost:5672 rabbit_userid=openstack rabbit_password= rabbit_virtual_host=/ rabbit_ha_queues=False notification_driver=cinder.openstack.common.notifier.rpc_notifier rpc_backend=cinder.openstack.common.rpc.impl_kombu control_exchange=openstack osapi_volume_listen=0.0.0.0 api_paste_config=/etc/cinder/api-paste.ini glance_host=192.168.0.6 auth_strategy=keystone enabled_backends= debug=False verbose=True log_dir=/var/log/cinder use_syslog=False iscsi_ip_address=192.168.0.6 volume_backend_name=DEFAULT iscsi_helper=tgtadm volumes_dir=/etc/cinder/volumes volume_group=cinder-volumes volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver [BRCD_FABRIC_EXAMPLE] [database] connection=mysql://cinder:@localhost/cinder idle_timeout=3600 [fc-zone-manager] [keymgr] [keystone_authtoken] [matchmaker_ring] [ssl] [root@node1 cinder(openstack_admin)]# lvdisplay cinder-volumes --- Logical volume --- LV Path /dev/cinder-volumes/cinder-volumes LV Name cinder-volumes VG Name cinder-volumes LV UUID wxnyZJ-3BM0-Dnzt-h2Pt-k6qY-1lFG-CEuwfp LV Write Access read/write LV Creation host, time node1.local, 2014-07-10 21:59:48 -0700 LV Status available # open 0 LV Size 4.00 GiB Current LE 1023 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2

10 years, 9 months

2
1
0 / 0

[Rdo-list] [Heads-up] RDO Bug triage tomorrow [15JUL2014]

by Kashyap Chamarthy

Heya, It's that time again! Tomorrow (3rd Tuesday of the month) is RDO bug triage day. If you have some spare cycles, please join us in helping triage bugs/root-cause analysis. Here's some details to get started[1] with bug triaging. Briefly, current state of RDO bugs: - NEW, ASSIGNED, ON_DEV : 177 - MODIFIED, POST, ON_QA : 125 All the bugs with their descriptions in plain text here[2]. As usual, if you have questions/comments, post to this list or on #rdo IRC channel on Freenode. [1] http://openstack.redhat.com/RDO-BugTriage [2] http://kashyapc.fedorapeople.org/virt/openstack/rdo-bug-status/all-rdo-bu... -- /kashyap

10 years, 9 months

1
1
0 / 0

[Rdo-list] Fwd: [Bug 1117871] Could not evaluate: Could not find init script for 'messagebus' - RDO Icehouse AIO on CentOS 7

by Steve Gordon

Is anyone able to take it looks - seems like we have an issue on the recently release CentOS 7? ----- Forwarded Message ----- > From: bugzilla(a)redhat.com > To: sgordon(a)redhat.com > Sent: Friday, July 11, 2014 12:37:23 PM > Subject: [Bug 1117871] Could not evaluate: Could not find init script for 'messagebus' - RDO Icehouse AIO on CentOS 7 > > https://bugzilla.redhat.com/show_bug.cgi?id=1117871 > > Alejandro Cortina <alitox(a)gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |alitox(a)gmail.com > > > > --- Comment #1 from Alejandro Cortina <alitox(a)gmail.com> --- > I had a different error but I fixed with the same solution provided in: > > https://ask.openstack.org/en/question/35705/attempt-of-rdo-aio-install-ic... > > "..replace content /etc/redhat-release with "Fedora release 20 (Heisenbug)" > and > rerun packstack --allinone. In meantime I have IceHouse AIO Instance on > CentOS > 7 completely functional." > > Terminal: > > ERROR : Error appeared during Puppet run: 192.168.11.19_prescript.pp > Error: comparison of String with 7 failed at > /var/tmp/packstack/2761ac128766421ab10ff27c754a6285/manifests/192.168.11.19_prescript.pp:15 > on node stack1.local.lan > You will find full trace in log > /var/tmp/packstack/20140712-012704-8RBDNB/manifests/192.168.11.19_prescript.pp.log > Please check log file > /var/tmp/packstack/20140712-012704-8RBDNB/openstack-setup.log for more > information > > > openstack-setup.log: > > ... > tar --dereference -cpzf - apache ceilometer certmonger cinder concat firewall > glance heat horizon inifile keystone memcached mongodb mysql neutron nova > nssdb > openstack packstack qp > id rabbitmq rsync ssh stdlib swift sysctl tempest vcsrepo vlan vswitch xinetd > | > ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null > root(a)192.168.11.19 tar -C > /var/tmp/packstack/2761ac128766421ab10ff27c754a6285/modules -xpzf - > 2014-07-12 01:28:57::ERROR::run_setup::920::root:: Traceback (most recent > call > last): > File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", > line 915, in main > _main(confFile) > File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", > line 605, in _main > runSequences() > File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", > line 584, in runSequences > controller.runAllSequences() > File > "/usr/lib/python2.7/site-packages/packstack/installer/setup_controller.py", > line 68, in runAllSequences > sequence.run(config=self.CONF, messages=self.MESSAGES) > File > "/usr/lib/python2.7/site-packages/packstack/installer/core/sequences.py", > line > 98, in run > step.run(config=config, messages=messages) > File > "/usr/lib/python2.7/site-packages/packstack/installer/core/sequences.py", > line > 44, in run > raise SequenceError(str(ex)) > SequenceError: Error appeared during Puppet run: 192.168.11.19_prescript.pp > Error: comparison of String with 7 failed at > /var/tmp/packstack/2761ac128766421ab10ff27c754a6285/manifests/192.168.11.19_prescript.pp:15 > on node stack1.local.lan > You will find full trace in log > /var/tmp/packstack/20140712-012704-8RBDNB/manifests/192.168.11.19_prescript.pp.log > > 2014-07-12 01:28:57::INFO::shell::81::root:: [192.168.11.19] Executing > script: > rm -rf /var/tmp/packstack/2761ac128766421ab10ff27c754a6285 > [root@stack1 20140712-012704-8RBDNB]# > > > 192.168.11.19_prescript.pp.log: > > Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults > Error: comparison of String with 7 failed at > /var/tmp/packstack/2761ac128766421ab10ff27c754a6285/manifests/192.168.11.19_prescript.pp:15 > on node stack1.local.lan > Wrapped exception: > comparison of String with 7 failed > Error: comparison of String with 7 failed at > /var/tmp/packstack/2761ac128766421ab10ff27c754a6285/manifests/192.168.11.19_prescript.pp:15 > on node stack1.local.lan > > -- > You are receiving this mail because: > You reported the bug. > -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform

10 years, 9 months

1
0
0 / 0

[Rdo-list] Need Help: openstack Repos Are Missing

by Chandra Ganguly (ganguly)

Hi RedHat/Openstack Team I am trying to install foreman and I am seeing the following RPM missing, which is causing my the download of my foreman-installer to fail. Can somebody let me know what is the new openstack repo to get; I am running it on RHEL6.5 [root@foreman-server ~]# subscription-manager repos --enable rhel-6-server-openstack-4.0-rpms Error: rhel-6-server-openstack-4.0-rpms is not a valid repo ID. Use --list option to see valid repos. root@foreman-server ~]# subscription-manager repos --list | grep openstack [root@foreman-server ~]# yum install openstack-foreman-installer foreman-selinux Loaded plugins: priorities, product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-optional-rpms | 3.5 kB 00:00 rhel-6-server-realtime-rpms | 3.8 kB 00:00 rhel-6-server-rpms | 3.7 kB 00:00 rhel-ha-for-rhel-6-server-rpms | 3.7 kB 00:00 rhel-hpn-for-rhel-6-server-rpms | 3.7 kB 00:00 rhel-lb-for-rhel-6-server-rpms | 3.7 kB 00:00 rhel-rs-for-rhel-6-server-rpms | 3.7 kB 00:00 rhel-sap-for-rhel-6-server-rpms | 3.7 kB 00:00 rhel-sap-hana-for-rhel-6-server-rpms | 2.8 kB 00:00 rhel-scalefs-for-rhel-6-server-rpms | 3.7 kB 00:00 rhel-server-6-rhds-9-rpms | 3.1 kB 00:00 rhel-server-dts-6-rpms | 2.9 kB 00:00 rhel-server-dts2-6-rpms | 2.6 kB 00:00 rhel-sjis-for-rhel-6-server-rpms | 3.1 kB 00:00 Setting up Install Process No package openstack-foreman-installer available. No package foreman-selinux available. Error: Nothing to do Thanks Chandra

10 years, 9 months

3
2
0 / 0

[Rdo-list] RDO Folsom and Grizzly EOL

by Rich Bowen

RDO's mission is to provide latest stable OpenStack packages. As such, anything back 2 from latest, we move into EOL[1] to indicate that we're not actively working on those packages any more. (Much like the Fedora release and EOL process [2] ) We've gotten a little behind on this over the last two cycles. In the next few days we'll be moving Folsom and Grizzly into the EOL directory to indicate their status. Also, a few weeks after the Juno 3 release[3] in September, we'll be moving Havana to EOL status as well. Thanks. --Rich [1] http://repos.fedorapeople.org/repos/openstack/EOL/ [2] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Sche... [3] https://wiki.openstack.org/wiki/Juno_Release_Schedule -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

10 years, 9 months

1
0
0 / 0

[Rdo-list] Attempt of RDO AIO install IceHouse on CentOS 7

by Boris Derzhavets

https://ask.openstack.org/en/question/35705/attempt-of-rdo-aio-install-ic...

10 years, 9 months

2
1
0 / 0

[Rdo-list] ssh access to a fedora cloud image instance

by Madko

Hi, I have an almost working openstack platform deployed via foreman. When I launch an instance from the Fedora 19 cloud image, everything seems fine, the VM is running on one of my hypervisor, but I can't access it (ping is ok)... I'm following this documentation http://openstack.redhat.com/Running_an_instance I only get a permission denied when I do the last part: ssh -l root -i my_key_pair.pem floating_ip_address I also try by importing an ssh key. Same error. In the VM console, I see that CloudInit service is starting inside the VM, no error are shown here. So my question is: Where are the logs for that parts (cloud init server) in openstack ? Is the above documentation fine ? best regards, -- Edouard Bourguignon

10 years, 9 months

5
13
0 / 0

[Rdo-list] Fwd: Fedora 21 Mass Branching

by Ihar Hrachyshka

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 To whom it may concern: Fedora 21 was branched, so from now on any fix to Icehouse should go to el6-icehouse (EL6) and f21 (next Fedora release + EL7). As for master, Juno should eventually arrive there. Till that time, we still probably want to track Icehouse backports there not to leave the branch without proper fixes that reached other Icehouse branches. /Ihar - -------- Original Message -------- Subject: Fedora 21 Mass Branching Date: Wed, 9 Jul 2014 01:22:30 -0500 From: Dennis Gilmore <dennis(a)ausil.us> Reply-To: devel(a)lists.fedoraproject.org To: devel-announce(a)lists.fedoraproject.org Hi All, Fedora 21 has been branched, please be sure to do a git pull --rebase to pick up the new branch, as an additional reminder rawhide/f22 has had inheritance cut off from previous releases, so this means that anything you do for f21 you also have to do in the master branch and do a build there. This is the same as we did for fedora 19 and 20. Dennis _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTvQ3GAAoJEC5aWaUY1u57J+cH/3tGhazyADj+RTRUrFqx0HOA hflUMxDkQS2yvRHnaaVSgzOaRV0GT6lXiewxMlTb3HcxsrF/CJp3EU+sUVwFewD/ 8VdFGOq8GMoElAzrZddPPzVsgd8biojWCMqCF8BYetzDlUCxLnz18SszdC/HPiGk yP3NjIex0AOP8YGZtUZg78QwHfTlKmzr2ozONt3qoe37sAoiOT16uLYu0FQmEA5n iRvO5wRmdyH1H/gozAVdkZVCzdvvZwQHUj9NF+dN7Pwbkg1qYzq8H8Seu0ijbv8n 98m153VH2IOVS82FD9wLXARcZ9fJjotK2nJZl2fsMdGcyEhoJ5A0tYmM4pYhCYM= =BPl6 -----END PGP SIGNATURE-----

10 years, 9 months

1
0
0 / 0

[Rdo-list] plan to add a parameter to config glance backend?

by Kun Huang

Hi all Is there such a plan now? Actually it's okay to adjust glance.conf only. Deploying ceph is not necessary. Thanks :) Gareth

10 years, 9 months

3
6
0 / 0

[Rdo-list] ERROR while installing RDO (rabbitmq-server)

by Fang, Lance

All, I am hoping you can help to resolve this. While installing RDO into a single VM, I continue to hit this problem. Appreciate any inputs .. == 10.110.80.62_mysql.pp: [ DONE ] 10.110.80.62_amqp.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.110.80.62_amqp.pp err: /Stage[main]/Rabbitmq::Service/Service[rabbitmq-server]/ensure: change from stopped to running failed: Could not start Service[rabbitmq-server]: Execution of '/sbin/service rabbitmq-server start' returned 1: at /var/tmp/packstack/754293704d5e4f66b3dd8532e8bd0300/modules/rabbitmq/manifests/service.pp:37 You will find full trace in log /var/tmp/packstack/20140702-123959-kJYnai/manifests/10.110.80.62_amqp.pp.log Please check log file /var/tmp/packstack/20140702-123959-kJYnai/openstack-setup.log for more information ----------------------------------------- Lance K. Fang Consultant Solutions Engineer Mobile: (510) 393-6208 ------------------------------------------

10 years, 10 months

4
10
0 / 0

[Rdo-list] Fwd: 50% discount on passes to Cloud Connect China in Shanghai, September 16-18

by Rich Bowen

For anyone in the Shanghai area ... -------- Original Message -------- Subject: [openstack-community] 50% discount on passes to Cloud Connect China in Shanghai, September 16-18 Date: Mon, 7 Jul 2014 09:22:16 -0500 (CDT) From: Kathy Cacciatore <kathyc(a)openstack.org> To: community(a)lists.openstack.org, marketing(a)lists.openstack.org Cloud Connect China <http://www.cloudconnectevent.cn/> is offering OpenStack community members and their clients and prospects a 50% discount on conference passes. It is limited to the first 50 people and must be used by July 31. Feel free to pass this on to other OpenStack people who may be interested in attending. OpenStack is sponsoring a half-day workshop on Monday, September 16, given by leading community members in China. Tom Fifield, OpenStack Community Manager, is a conference advisor and will also attending. Visit www.cloudconnectevent.cn/registration/registration_en.php <http://www.cloudconnectevent.cn/registration/registration_en.php>, and register for the package desired using registration code *CLOU14XP8ND. * Here are the packages with pre-discount prices. Note that a VIP Pass will be under $400! Thank you. cid:image007.png@01CF63B8.42D2FE90 -- Regards, Kathy Cacciatore OpenStack Industry Event Planner 1-512-970-2807 (mobile) Part time: Monday - Thursday, 9am - 2pm US CT kathyc(a)openstack.org

10 years, 10 months

1
0
0 / 0

[Rdo-list] Red Hat OpenStack Evaluation installation

by Lodgen, Brad

I have a quick question, as I may be misunderstanding the intention of the RHOS product and the installation/configuration guide. I'm using an evaluation, so I can't open tickets or I'll get forwarded to this mailing list. I've had a considerable number of issues installing and getting RHOS running in an initial "let's get started doing actual OpenStack tasks" kind of state. Is the RHOS product meant to be installable and running without going through the section of the installation/configuration guide that covers manual installation? Or are you expected to still go through the entire manual installation section? Because there are integral parts that are not discussed outside of the manual section; storage implementation, for example, is not mentioned outside of the manual installation section. And even the sections that are in the manual section basically say you can't rely solely on the Foreman host groups to set up storage, as there are some manual steps. Can someone shed some light on the product's intentions and how far it goes with setting up OpenStack for you?

10 years, 10 months

2
1
0 / 0

[Rdo-list] [Rdo-newsletter] July 2014 RDO Community Newsletter

by Rich Bowen

With the first milestone behind us this month, and the second one coming up fast - https://wiki.openstack.org/wiki/Juno_Release_Schedule - the Juno cycle seems to be speeding past. Here's some of what's happened in June, and what's coming in July. Hangouts: On June 6, Hugh Brock and the TripleO team talked about what's planned for OpenStack TripleO (the OpenStack deployment tool) in a Google Hangout. You can watch that at https://www.youtube.com/watch?v=ol5LuedIWBw On July 9, 15:00 UTC (11 am Eastern US time) Eoghan Glynn will be leading a Google Hangout in which he'll discuss what's new in Ceilometer in OpenStack Icehouse, and what's coming in Juno. Sign up to attend that event at https://plus.google.com/events/c6e8vjjn8klrf78ruhkr95j4tas Conferences: Also, in July, RDO will have a presence at OSCON, July 20-24, in Portland, Oregon, both in the Red Hat booth, and also in the Cloud track - http://www.oscon.com/oscon2014/public/schedule/topic/1113 If you're going to be at OSCON, drop by to say hi. In early August, the Flock conference will be held in Prague, Czech Republic - http://flocktofedora.com/ (August 6-9). In addition to all of the great Fedora content, Kashyap Chamarthy will be speaking about deploying OpenStack on Fedora. - http://sched.co/1kI1BWf Although the OpenStack Summit is still a few months away, be sure it's on your calendar. The summit will be held in Paris, November 3-7. More information and registration will be available in the next month or two. Blog posts: This month's blog posts from the RDO range from the technical to the philosophical. If you want to see the latest posts from the RDO community, you can follow at http://planet.rdoproject.org/ * Mark McLoughlin - An ideal openstack developer - http://blogs.gnome.org/markmc/2014/06/06/an-ideal-openstack-developer/ * Liz Blanchard - Moving forward as a User Experience Team in the OpenStack Juno release cycle - http://uxd-stackabledesign.rhcloud.com/moving-forward-user-experience-tea... * Rich Bowen - Red Hat at the OpenStack Summit (recordings) - http://drbacchus.com/red-hat-at-the-openstack-summit * Adam Young - Why POpen for OpenSSL calls - http://adam.younglogic.com/2014/06/why-popen-for-openssl-calls/ * Flavio Percoco - Marconi to AMQP: See you later - http://blog.flaper87.com/post/53a09586d987d23f49c777bf/ * Kashyap Chamarthy - On bug reporting. . . http://kashyapc.com/2014/06/22/on-bug-reporting/ eNovance Acquisition: The biggest news in the RDO world this month was Red Hat's acquisition of eNovance: http://www.redhat.com/about/news/press-archive/2014/6/red-hat-to-acquire-... eNovance's engineers are prolific contributors to the OpenStack upstream and respected names in the OpenStack community. And eNovance is 9th, by number of contributions, on the list of organizations contributing to the OpenStack code: http://activity.openstack.org/dash/browser/scm-companies.html Stay in Touch: The best ways to keep up with what's going on in the RDO community are: * Follow us on Twitter - http://twitter.com/rdocommunity * Google+ - http://tm3.org/rdogplus * rdo-list mailing list - http://www.redhat.com/mailman/listinfo/rdo-list * This newsletter - http://www.redhat.com/mailman/listinfo/rdo-newsletter * RDO Q&A - http://ask.openstack.org/ Thanks again for being part of the RDO community! -- Rich Bowen, OpenStack Community Liaison rbowen(a)redhat.com http://openstack.redhat.com _______________________________________________ Rdo-newsletter mailing list Rdo-newsletter(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-newsletter

10 years, 10 months

2
1
0 / 0

[Rdo-list] [RDO] What's coming in OpenStack Ceilometer: Google Hangout

by RDO Forum

rbowen started a discussion. What's coming in OpenStack Ceilometer: Google Hangout --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/977/whats-coming-in-openstac... Have a great day!

10 years, 10 months

1
0
0 / 0

Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List

by Lodgen, Brad

I think I figured it out. I started looking into saslauthd configuration and the configuration looked right, so I checked the service status, it was off. I checked the chkconfig status of saslauthd, and it was off for all init levels. I ran "/etc/init.d/saslauthd start", it turned on, so I changed the /etc/qpidd.conf "auth=no" to "auth=yes", and restarted qpidd service while tailing the /var/log/nova/compute.log of my compute node. It had 2 failure notices immediately, but then right after said communication was successful, and all my hypervisors are showing in the dashboard, communication in logs still looks good. I guess for some reason the Foreman controller host group doesn't turn on saslauthd service and doesn't turn on chkconfig for saslauthd? -----Original Message----- From: Lodgen, Brad Sent: Thursday, July 03, 2014 11:52 AM To: 'Rhys Oxenham' Cc: 'rdo-list(a)redhat.com' Subject: RE: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List Well, it had the same result with the second compute node I brought up which was a fresh system with RHEL6.5/RHOS package updates. I checked the nova.conf on controller and both compute nodes. All the same configuration, username, passwords, everything. rpc_backend=nova.openstack.common.rpc.impl_qpid qpid_hostname={controller node private IP} qpid_port=5672 #qpid_hosts=$qpid_hostname:$qpid_port qpid_username={same username} qpid_password={same password} #qpid_sasl_mechanisms= qpid_heartbeat=60 qpid_protocol=tcp qpid_tcp_nodelay=True #qpid_topology_version=1 Should the qpid client be installed on the compute nodes? Because this page notes that doing it manually, it should be (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_Op...) but, as you can see via Foreman host group deployment it IS installed on the controller and IS NOT on the compute nodes. [root@ctlr ~]# yum list installed | grep qpid This system is receiving updates from Red Hat Subscription Management. python-qpid.noarch 0.14-11.el6_3 @rhel-6-server-rpms qpid-cpp-client.x86_64 0.14-22.el6_3 @rhel-6-server-rpms qpid-cpp-server.x86_64 0.14-22.el6_3 @rhel-6-server-rpms [root@comp1 ~]# yum list installed | grep qpid This system is receiving updates from Red Hat Subscription Management. python-qpid.noarch 0.14-11.el6_3 @rhel-6-server-rpms [root@comp2 ~]# yum list installed | grep qpid This system is receiving updates from Red Hat Subscription Management. python-qpid.noarch 0.14-11.el6_3 @rhel-6-server-rpms -----Original Message----- From: Rhys Oxenham [mailto:roxenham@redhat.com] Sent: Thursday, July 03, 2014 11:22 AM To: Lodgen, Brad Cc: rdo-list(a)redhat.com Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List OK looks like a bug somewhere... if qpid auth is enabled it requires the authentication mechanism to be completed properly. See: http://qpid.apache.org/releases/qpid-0.14/books/AMQP-Messaging-Broker-CPP... >From looking at puppet-qpid it should have done this for you. Have you been able to reproduce this issue on a clean system? Cheers Rhys On 3 Jul 2014, at 17:16, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: > No worries. I understand you're busy and thank you for the assistance. To answer your question: yes, following the change and qpidd restart, the logs showed successful communication and the initial compute node showed up as a hypervisor in the dashboard. I also successfully added a second compute node. Success here relies upon disabling the puppet agent so it doesn't change auth back to yes; otherwise, communication fails. > > > -----Original Message----- > From: Rhys Oxenham [mailto:roxenham@redhat.com] > Sent: Thursday, July 03, 2014 11:13 AM > To: Lodgen, Brad > Cc: rdo-list(a)redhat.com > Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: > First Compute Node Doesn't Show Up in Hypervisor List > > Sorry I didn't respond to this... I have auth set to no in my environment, but that's just for testing. Do things work when auth is set to no and the service is restarted? > > On 3 Jul 2014, at 17:11, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: > >> Follow-up from yesterday... is this the same default in RDO, to have qpidd.conf default to auth=yes? >> >> Does that mean I have something on the compute side misconfigured? It looks to me like the username/password is the same on the controller/compute. >> >> For now, I've had to disable puppet agent on the controller, as it keeps resetting "auth=no" back to "auth=yes", and I don't see a host group parameter that would change that. >> >> >> >> >> -----Original Message----- >> From: Lodgen, Brad >> Sent: Wednesday, July 02, 2014 2:01 PM >> To: 'Rhys Oxenham' >> Cc: 'rdo-list(a)redhat.com' >> Subject: RE: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >> First Compute Node Doesn't Show Up in Hypervisor List >> >> So even though the default controller puppet module configures qpidd.conf to say "auth=yes", I changed it to "auth=no" and restarted qpidd service. I now see my compute host in the dashboard. >> >> Is that a misconfiguration in RHOSv4 that I should submit for a change somewhere? >> >> >> >> -----Original Message----- >> From: Lodgen, Brad >> Sent: Wednesday, July 02, 2014 12:53 PM >> To: 'Rhys Oxenham' >> Cc: 'rdo-list(a)redhat.com' >> Subject: RE: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >> First Compute Node Doesn't Show Up in Hypervisor List >> >> The settings in the controller/compute host group parameters regarding qpidd are all default, except for the host, which is the private IP of the controller. >> >> I haven't made any changes outside of the Foreman host group parameters and I don't see any compute host group parameters that would allow me to specify whether a service uses Qpid authentication or not. >> >> I did change the compute host group parameter "auth_host" and "nova_host" (originally by default set to 127.0.0.1) to the private IP of the controller. Would that have any effect? >> >> >> -----Original Message----- >> From: Rhys Oxenham [mailto:roxenham@redhat.com] >> Sent: Wednesday, July 02, 2014 12:35 PM >> To: Lodgen, Brad >> Cc: rdo-list(a)redhat.com >> Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >> First Compute Node Doesn't Show Up in Hypervisor List >> >> Have you specified Qpid authentication in any of the rest of the services? I suspect that Qpid is set up to use authentication but none of the other services are. >> >> On 2 Jul 2014, at 18:30, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: >> >>> # GENERATED BY PUPPET >>> # >>> # Configuration file for qpidd. Entries are of the form: >>> # name=value >>> # >>> # (Note: no spaces on either side of '='). Using default settings: >>> # "qpidd --help" or "man qpidd" for more details. >>> port=5672 >>> max-connections=65535 >>> worker-threads=17 >>> connection-backlog=10 >>> auth=yes >>> realm=QPID >>> >>> >>> -----Original Message----- >>> From: Rhys Oxenham [mailto:roxenham@redhat.com] >>> Sent: Wednesday, July 02, 2014 12:27 PM >>> To: Lodgen, Brad >>> Cc: rdo-list(a)redhat.com >>> Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >>> First Compute Node Doesn't Show Up in Hypervisor List >>> >>> No worries! >>> >>> Can you paste out your /etc/qpidd.conf file from the controller? >>> (Make sure you sanitise the output) >>> >>> Cheers >>> Rhys >>> >>> >>> On 2 Jul 2014, at 18:23, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: >>> >>>> Thanks for the quick response! Based on the below log findings and what I just found searching, is this caused by the controller host group parameter "freeipa" being set to the default "false"? Change it to "true"? >>>> >>>> >>>> >>>> On the compute node, I'm seeing this over and over in the compute log: >>>> >>>> Unable to connect to AMQP server: Error in sasl_client_start (-1) >>>> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >>>> Minor code may provide more information (Cannot determine realm for >>>> numeric host address). Sleeping 5 seconds >>>> >>>> On the controller conductor log: >>>> >>>> Unable to connect to AMQP server: Error in sasl_client_start (-1) >>>> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >>>> Minor code may provide more information (Cannot determine realm for >>>> numeric host address). Sleeping 5 seconds >>>> >>>> In the controller messages file: >>>> >>>> python: GSSAPI Error: Unspecified GSS failure. Minor code may >>>> provide more information (Cannot determine realm for numeric host >>>> address) >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Rhys Oxenham [mailto:roxenham@redhat.com] >>>> Sent: Wednesday, July 02, 2014 12:14 PM >>>> To: Lodgen, Brad >>>> Cc: rdo-list(a)redhat.com >>>> Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >>>> First Compute Node Doesn't Show Up in Hypervisor List >>>> >>>> Hi Brad, >>>> >>>> Have you checked the nova-compute logs in /var/log/nova/compute.log >>>> (on your new compute node?) >>>> >>>> This should point towards why it's unable to connect/start etc. I suspect that it's unable to join the message queue, and hence show up as an available hypervisor. >>>> >>>> Many thanks >>>> Rhys >>>> >>>> On 2 Jul 2014, at 18:05, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I have an issue where I've just done the initial setup and added a controller node, it finished, then I added a compute node, it finished, but I don't see the compute node in the hypervisor list on the dashboard. I'm using the RH OpenStack evaluation version 4. I have five hosts present in Foreman. >>>>> >>>>> -Foreman host (purely for Foreman) -Controller host (applied >>>>> Controller(Nova) host group) -Compute Host (applied Compute(Nova) >>>>> host group) >>>>> -2 other hosts (not host group applied, but one will be compute >>>>> and one will be storage) >>>>> >>>>> Did I miss something on the controller/compute host group parameters that would cause it to not show up in the dashboard? >>>>> _______________________________________________ >>>>> Rdo-list mailing list >>>>> Rdo-list(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>> >> >

10 years, 10 months

1
0
0 / 0

Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List

by Lodgen, Brad

Follow-up from yesterday... is this the same default in RDO, to have qpidd.conf default to auth=yes? Does that mean I have something on the compute side misconfigured? It looks to me like the username/password is the same on the controller/compute. For now, I've had to disable puppet agent on the controller, as it keeps resetting "auth=no" back to "auth=yes", and I don't see a host group parameter that would change that. -----Original Message----- From: Lodgen, Brad Sent: Wednesday, July 02, 2014 2:01 PM To: 'Rhys Oxenham' Cc: 'rdo-list(a)redhat.com' Subject: RE: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List So even though the default controller puppet module configures qpidd.conf to say "auth=yes", I changed it to "auth=no" and restarted qpidd service. I now see my compute host in the dashboard. Is that a misconfiguration in RHOSv4 that I should submit for a change somewhere? -----Original Message----- From: Lodgen, Brad Sent: Wednesday, July 02, 2014 12:53 PM To: 'Rhys Oxenham' Cc: 'rdo-list(a)redhat.com' Subject: RE: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List The settings in the controller/compute host group parameters regarding qpidd are all default, except for the host, which is the private IP of the controller. I haven't made any changes outside of the Foreman host group parameters and I don't see any compute host group parameters that would allow me to specify whether a service uses Qpid authentication or not. I did change the compute host group parameter "auth_host" and "nova_host" (originally by default set to 127.0.0.1) to the private IP of the controller. Would that have any effect? -----Original Message----- From: Rhys Oxenham [mailto:roxenham@redhat.com] Sent: Wednesday, July 02, 2014 12:35 PM To: Lodgen, Brad Cc: rdo-list(a)redhat.com Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List Have you specified Qpid authentication in any of the rest of the services? I suspect that Qpid is set up to use authentication but none of the other services are. On 2 Jul 2014, at 18:30, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: > # GENERATED BY PUPPET > # > # Configuration file for qpidd. Entries are of the form: > # name=value > # > # (Note: no spaces on either side of '='). Using default settings: > # "qpidd --help" or "man qpidd" for more details. > port=5672 > max-connections=65535 > worker-threads=17 > connection-backlog=10 > auth=yes > realm=QPID > > > -----Original Message----- > From: Rhys Oxenham [mailto:roxenham@redhat.com] > Sent: Wednesday, July 02, 2014 12:27 PM > To: Lodgen, Brad > Cc: rdo-list(a)redhat.com > Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: > First Compute Node Doesn't Show Up in Hypervisor List > > No worries! > > Can you paste out your /etc/qpidd.conf file from the controller? (Make > sure you sanitise the output) > > Cheers > Rhys > > > On 2 Jul 2014, at 18:23, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: > >> Thanks for the quick response! Based on the below log findings and what I just found searching, is this caused by the controller host group parameter "freeipa" being set to the default "false"? Change it to "true"? >> >> >> >> On the compute node, I'm seeing this over and over in the compute log: >> >> Unable to connect to AMQP server: Error in sasl_client_start (-1) >> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (Cannot determine realm for >> numeric host address). Sleeping 5 seconds >> >> On the controller conductor log: >> >> Unable to connect to AMQP server: Error in sasl_client_start (-1) >> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (Cannot determine realm for >> numeric host address). Sleeping 5 seconds >> >> In the controller messages file: >> >> python: GSSAPI Error: Unspecified GSS failure. Minor code may >> provide more information (Cannot determine realm for numeric host >> address) >> >> >> >> >> >> -----Original Message----- >> From: Rhys Oxenham [mailto:roxenham@redhat.com] >> Sent: Wednesday, July 02, 2014 12:14 PM >> To: Lodgen, Brad >> Cc: rdo-list(a)redhat.com >> Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >> First Compute Node Doesn't Show Up in Hypervisor List >> >> Hi Brad, >> >> Have you checked the nova-compute logs in /var/log/nova/compute.log >> (on your new compute node?) >> >> This should point towards why it's unable to connect/start etc. I suspect that it's unable to join the message queue, and hence show up as an available hypervisor. >> >> Many thanks >> Rhys >> >> On 2 Jul 2014, at 18:05, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: >> >>> Hi folks, >>> >>> I have an issue where I've just done the initial setup and added a controller node, it finished, then I added a compute node, it finished, but I don't see the compute node in the hypervisor list on the dashboard. I'm using the RH OpenStack evaluation version 4. I have five hosts present in Foreman. >>> >>> -Foreman host (purely for Foreman) >>> -Controller host (applied Controller(Nova) host group) -Compute Host >>> (applied Compute(Nova) host group) >>> -2 other hosts (not host group applied, but one will be compute and >>> one will be storage) >>> >>> Did I miss something on the controller/compute host group parameters that would cause it to not show up in the dashboard? >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >> >

10 years, 10 months

2
4
0 / 0

Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List

by Lodgen, Brad

So even though the default controller puppet module configures qpidd.conf to say "auth=yes", I changed it to "auth=no" and restarted qpidd service. I now see my compute host in the dashboard. Is that a misconfiguration in RHOSv4 that I should submit for a change somewhere? -----Original Message----- From: Lodgen, Brad Sent: Wednesday, July 02, 2014 12:53 PM To: 'Rhys Oxenham' Cc: 'rdo-list(a)redhat.com' Subject: RE: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List The settings in the controller/compute host group parameters regarding qpidd are all default, except for the host, which is the private IP of the controller. I haven't made any changes outside of the Foreman host group parameters and I don't see any compute host group parameters that would allow me to specify whether a service uses Qpid authentication or not. I did change the compute host group parameter "auth_host" and "nova_host" (originally by default set to 127.0.0.1) to the private IP of the controller. Would that have any effect? -----Original Message----- From: Rhys Oxenham [mailto:roxenham@redhat.com] Sent: Wednesday, July 02, 2014 12:35 PM To: Lodgen, Brad Cc: rdo-list(a)redhat.com Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List Have you specified Qpid authentication in any of the rest of the services? I suspect that Qpid is set up to use authentication but none of the other services are. On 2 Jul 2014, at 18:30, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: > # GENERATED BY PUPPET > # > # Configuration file for qpidd. Entries are of the form: > # name=value > # > # (Note: no spaces on either side of '='). Using default settings: > # "qpidd --help" or "man qpidd" for more details. > port=5672 > max-connections=65535 > worker-threads=17 > connection-backlog=10 > auth=yes > realm=QPID > > > -----Original Message----- > From: Rhys Oxenham [mailto:roxenham@redhat.com] > Sent: Wednesday, July 02, 2014 12:27 PM > To: Lodgen, Brad > Cc: rdo-list(a)redhat.com > Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: > First Compute Node Doesn't Show Up in Hypervisor List > > No worries! > > Can you paste out your /etc/qpidd.conf file from the controller? (Make > sure you sanitise the output) > > Cheers > Rhys > > > On 2 Jul 2014, at 18:23, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: > >> Thanks for the quick response! Based on the below log findings and what I just found searching, is this caused by the controller host group parameter "freeipa" being set to the default "false"? Change it to "true"? >> >> >> >> On the compute node, I'm seeing this over and over in the compute log: >> >> Unable to connect to AMQP server: Error in sasl_client_start (-1) >> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (Cannot determine realm for >> numeric host address). Sleeping 5 seconds >> >> On the controller conductor log: >> >> Unable to connect to AMQP server: Error in sasl_client_start (-1) >> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (Cannot determine realm for >> numeric host address). Sleeping 5 seconds >> >> In the controller messages file: >> >> python: GSSAPI Error: Unspecified GSS failure. Minor code may >> provide more information (Cannot determine realm for numeric host >> address) >> >> >> >> >> >> -----Original Message----- >> From: Rhys Oxenham [mailto:roxenham@redhat.com] >> Sent: Wednesday, July 02, 2014 12:14 PM >> To: Lodgen, Brad >> Cc: rdo-list(a)redhat.com >> Subject: Re: [Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: >> First Compute Node Doesn't Show Up in Hypervisor List >> >> Hi Brad, >> >> Have you checked the nova-compute logs in /var/log/nova/compute.log >> (on your new compute node?) >> >> This should point towards why it's unable to connect/start etc. I suspect that it's unable to join the message queue, and hence show up as an available hypervisor. >> >> Many thanks >> Rhys >> >> On 2 Jul 2014, at 18:05, Lodgen, Brad <Brad.Lodgen(a)centurylink.com> wrote: >> >>> Hi folks, >>> >>> I have an issue where I've just done the initial setup and added a controller node, it finished, then I added a compute node, it finished, but I don't see the compute node in the hypervisor list on the dashboard. I'm using the RH OpenStack evaluation version 4. I have five hosts present in Foreman. >>> >>> -Foreman host (purely for Foreman) >>> -Controller host (applied Controller(Nova) host group) -Compute Host >>> (applied Compute(Nova) host group) >>> -2 other hosts (not host group applied, but one will be compute and >>> one will be storage) >>> >>> Did I miss something on the controller/compute host group parameters that would cause it to not show up in the dashboard? >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >> >

10 years, 10 months

1
0
0 / 0

[Rdo-list] RH OpenStack v4 Evaluation: Initial Setup: First Compute Node Doesn't Show Up in Hypervisor List

by Lodgen, Brad

Hi folks, I have an issue where I've just done the initial setup and added a controller node, it finished, then I added a compute node, it finished, but I don't see the compute node in the hypervisor list on the dashboard. I'm using the RH OpenStack evaluation version 4. I have five hosts present in Foreman. -Foreman host (purely for Foreman) -Controller host (applied Controller(Nova) host group) -Compute Host (applied Compute(Nova) host group) -2 other hosts (not host group applied, but one will be compute and one will be storage) Did I miss something on the controller/compute host group parameters that would cause it to not show up in the dashboard?

10 years, 10 months

2
6
0 / 0

[Rdo-list] Problem regarding mysql.pp

by sharad aggarwal

Dear Admin, I am trying to install rdo latest release i.e. openstack icehouse on CentOS 6.5 (64 bit) nut I am getting following error, *Applying 192.168.11.6_prescript.pp* *192.168.11.6_prescript.pp: [ DONE ]* *Applying 192.168.11.6_mysql.pp* *Applying 192.168.11.6_amqp.pp* *192.168.11.6_mysql.pp: [ ERROR ]* *Applying Puppet manifests [ ERROR ]* *ERROR : Error appeared during Puppet run: 192.168.11.6_mysql.pp* *Package mariadb-galera-server has not been found in enabled Yum repos.* *You will find full trace in log /var/tmp/packstack/20140702-152003-VVOe1r/manifests/192.168.11.6_mysql.pp.log* *Please check log file /var/tmp/packstack/20140702-152003-VVOe1r/openstack-setup.log for more information* I would like to inform you that I have installed MariaDB-Galera-server and removed mysql-server. Earlier I was getting error with prescript.pp but that I resolved by making a timeout changes in netns.pp file. I have also executed "yum install iproute iputils". Attached file holds the output */var/tmp/packstack/20140702-152003-VVOe1r/manifests/192.168.11.6_mysql.pp.log* Please help ASAP. Thanks -- Regards, Sharad Aggarwal +91 9999 197 992

10 years, 10 months

1
0
0 / 0

[Rdo-list] Nested RDO Icehouse nova-compute KVM / QEMU issues due to -cpu host

by Steven Ellis

So I'm having issues nesting RDO on my T440s laptop (Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz), and I'm hoping someone on the list can help My Physical Host (L0) is Fedora 19 running 3.14.4-100.fc19.x86_64 with nesting turned on My OpenStack Host is RHEL 6.5 or RHEL 7 (L1) My Guest is Cirros (L2) I'm installing RDO Icehouse under RHEL via packstack --allinone --os-neutron-install=n I then try to startup a Cirros guest (L2) and the guest never spawns Taking a look at the qemu command line it looks as follows /usr/libexec/qemu-kvm \ -global virtio-blk-pci.scsi=off \ -nodefconfig \ -nodefaults \ -nographic \ -machine accel=kvm:tcg \ -cpu host,+kvmclock \ -m 500 \ -no-reboot \ -kernel /var/tmp/.guestfs-497/kernel.2647 \ -initrd /var/tmp/.guestfs-497/initrd.2647 \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/lib/nova/instances/3ae072b4-f4bf-42cf-b3ea-27d9768bc4df/disk,cache=none,format=qcow2,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/var/tmp/.guestfs-497/root.2647,snapshot=on,id=appliance,if=none,cache=unsafe \ -device scsi-hd,drive=appliance \ -device virtio-serial \ -serial stdio \ -device sga \ -chardev socket,path=/tmp/libguestfsKGbB3D/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 TERM=linux The issue appears to be running with "-cpu host" with this nesting combination. Now if I run the qemu command directly on RHEL7 (L1) I get this error KVM: entry failed, hardware error 0x7 Under RHEL 6.5 (L1) it is similar but not identical kvm: unhandled exit 7 In both cases on my Fedora physical host (L0) I see nested_vmx_run: VMCS MSR_{LOAD,STORE} unsupported There does appear to be a Red Hat bugzilla for RHEL7 relating to this but not for RHEL6 - https://bugzilla.redhat.com/show_bug.cgi?id=1038427 I can reproduce this issue using both RHEL 6.5 and RHEL 7 as my OpenStack Host (L1). Has anyone else hit this issue? Next I tried a work around of editing the /etc/nova/nova.conf file and forcing the CPU type for my guests under OpenStack #cpu_mode=none cpu_mode=custom # Set to a named libvirt CPU model (see names listed in # /usr/share/libvirt/cpu_map.xml). Only has effect if # cpu_mode="custom" and virt_type="kvm|qemu" (string value) # Deprecated group;name - DEFAULT;libvirt_cpu_model #cpu_model=<None> cpu_model=Conroe Problem is qemu is still run with "-cpu host,+kvmclock" So am I hitting a secondary bug with nova-compute or is there another way to force OpenStack to select a particular CPU subset for Nova? Steve -- Steven Ellis Solution Architect - Red Hat New Zealand <http://www.redhat.co.nz/> *E:* sellis(a)redhat.com <mailto:sellis@redhat.com>

10 years, 10 months

2
1
0 / 0

[Rdo-list] how could I set netmask in iptables chain?

by Kun Huang

In a RDO setup, I could get this in my iptables: -A INPUT -s 192.168.164.63/32 -p tcp ...... But I need <ip address>/16 instead. When seeing firewall.pp, I find this is no such a parameter about netmask. So is it possible to set my own netmask?

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

dev July 2014