[openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

Vega Cai luckyvega.g at gmail.com
Tue Mar 1 08:11:04 UTC 2016


Hi, Pengfei,

I suppose you are using "internal network" in virtual box to connect your
virtual machines, and I find a link that seems to related to your problem.

https://forums.virtualbox.org/viewtopic.php?f=1&t=38037

BR
Zhiyuan

On 1 March 2016 at 11:14, Vega Cai <luckyvega.g at gmail.com> wrote:

> Hi, All,
>
> Let's move the discussion to #openstack-tricircle in IRC.
>
> BR
> Zhiyuan
>
> On 1 March 2016 at 11:07, Yipei Niu <newypei at gmail.com> wrote:
>
>> Hi, all,
>>
>> The bug of deploying devstack with two-node configuration is already
>> fixed. According to the official document, I have already installed
>> devstack in two nodes successfully.
>>
>> Moreover, I am still trying to play tricircle in two nodes. When
>> installing tricircle to node1, I still encounter the same error as before.
>> The link is http://paste.openstack.org/show/488682/.
>>
>> Best regards,
>> Yipei
>>
>> On Tue, Mar 1, 2016 at 10:56 AM, joehuang <joehuang at huawei.com> wrote:
>>
>>> Hi, Yipei,
>>>
>>>
>>>
>>> The issue is that the OS_REGION_NAME should be “Pod2” for the Node2 for
>>> Nova,Cinder, Neutron endpoint registration in KeyStone, but when creating
>>> endpoint in Keystone, devstack will use command like “openstack endpoint
>>> create” to access KeyStone, the OS_REGION_NAME should be the region name
>>> where the KeyStone located, in two-nodes installation, it should be
>>> “RegionOne” for the command itself.
>>>
>>>
>>>
>>> So it can be fixed by adding one more configurable global variable to
>>> separate KeyStone region name and other services(Nova,Cinder,Neutron)
>>> region name.
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Chaoyi Huang ( Joe Huang )
>>>
>>>
>>>
>>> *From:* Yipei Niu [mailto:newypei at gmail.com]
>>> *Sent:* Monday, February 29, 2016 10:02 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Cc:* Vega Cai; joehuang; 时鹏飞
>>> *Subject:* Re: [tricircle] playing tricircle with devstack under
>>> two-region configuration
>>>
>>>
>>>
>>> Hi Pengfei,
>>>
>>>
>>>
>>> I also encounter the same error when installing devstack on node2. I
>>> insert a command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and
>>> it works. However, I am not sure whether it is correct. I am trying to
>>> verify it. Recently, I try to re-install devstack on node1, but I encounter
>>> some errors. The link is http://paste.openstack.org/show/488005/. Do
>>> you have any suggestion about it?
>>>
>>>
>>>
>>> To Joe and Zhiyuan, could you please give me some advice about how to
>>> solve it?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Yipei
>>>
>>>
>>>
>>> On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu <newypei at gmail.com> wrote:
>>>
>>> Hi Joe and Zhiyuan,
>>>
>>>
>>>
>>> My VM has recovered. When I re-install devstack in node1, I encounter
>>> the following errors.
>>>
>>>
>>>
>>> The info in stack.sh.log is as follows:
>>>
>>>
>>>
>>> 2016-02-23 11:18:27.238 | Error: Service n-sch is not running
>>>
>>> 2016-02-23 11:18:27.238 | +
>>> /home/stack/devstack/functions-common:service_check:L1625:   '[' -n
>>> /opt/stack/status/stack/n-sch.failure ']'
>>>
>>> 2016-02-23 11:18:27.238 | +
>>> /home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More
>>> details about the above errors can be found with screen, with
>>> ./rejoin-stack.sh'
>>>
>>> 2016-02-23 11:18:27.238 | +
>>> /home/stack/devstack/functions-common:die:L186:   local exitcode=0
>>>
>>> 2016-02-23 11:18:27.239 | [Call Trace]
>>>
>>> 2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
>>>
>>> 2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
>>>
>>> 2016-02-23 11:18:27.261 | [ERROR]
>>> /home/stack/devstack/functions-common:1626 More details about the above
>>> errors can be found with screen, with ./rejoin-stack.sh
>>>
>>> 2016-02-23 11:18:28.271 | Error on exit
>>>
>>> 2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied
>>>
>>>
>>>
>>> The info in n-sch.log is as follows:
>>>
>>>
>>>
>>> stack at nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler
>>> --config-file /et ^Mc/nova/nova.conf & echo $!
>>> >/opt/stack/status/stack/n-sch.pid; fg || echo "n-sch ^M failed to start" |
>>> tee "/opt/stack/status/stack/n-sch.failure"
>>>
>>> [1] 29467
>>>
>>> /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
>>>
>>> 2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m]
>>> ^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from
>>> 'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend
>>> /usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
>>>
>>> 2016-02-23 19:13:00.300 ^[[01;33mWARNING
>>> oslo_reports.guru_meditation_report [^[[00;36m-^[[01;33m]
>>> ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 and SIGUSR2 by
>>> default for backward compatibility. SIGUSR1 will no longer be registered in
>>> a future release, so please use SIGUSR2 to generate reports.^[[00m
>>>
>>> 2016-02-23 19:13:00.304 ^[[01;31mCRITICAL nova [^[[00;36m-^[[01;31m]
>>> ^[[01;35m^[[01;31mValueError: Empty module name
>>>
>>> ^[[00m
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mTraceback
>>> (most recent call last):
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/usr/local/bin/nova-scheduler", line 10, in <module>
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>  sys.exit(main())
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/opt/stack/nova/nova/cmd/scheduler.py", line 43, in main
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>  topic=CONF.scheduler_topic)
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/opt/stack/nova/nova/service.py", line 281, in create
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>  db_allowed=db_allowed)
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/opt/stack/nova/nova/service.py", line 167, in __init__
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>  self.manager = manager_class(host=self.host, *args, **kwargs)
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/opt/stack/nova/nova/scheduler/manager.py", line 49, in __init__
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>  self.driver = importutils.import_object(scheduler_driver)
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line
>>> 44, in import_object
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m    return
>>> import_class(import_str)(*args, **kwargs)
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line
>>> 30, in import_class
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>  __import__(mod_str)
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mValueError:
>>> Empty module name
>>>
>>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>>
>>> n-sch failed to start
>>>
>>>
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Yipei
>>>
>>>
>>>
>>> On Tue, Feb 23, 2016 at 10:23 AM, Yipei Niu <newypei at gmail.com> wrote:
>>>
>>> Hi Jeo,
>>>
>>>
>>>
>>> I have checked. The Neutron API has not started, but no process is
>>> listening 9696.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Yipei
>>>
>>>
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160301/7ce2778c/attachment.html>


More information about the OpenStack-dev mailing list