Re: [openstack-dev] Does the openstack ci vms start each time clear up enough?

[Vega Cai]

To test whether it's our new patch that causes the problem, I submitted a
dummy patch[1] to trigger CI and the CI failed again. Checking the log of
nova scheduler, it's very strange that the scheduling starts with 0 host at
the beginning.

May 06 09:40:34.358585

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
oslo_service.periodic_task [None
req-008ee30a-47a1-40a2-bf64-cb0f1719806e None None] Running periodic
task SchedulerManager._run_periodic_tasks {{(pid=23795)
run_periodic_tasks
/usr/local/lib/python2.7/dist-packages/oslo_service/periodic_task.py:215}}May
06 09:41:23.968029

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
nova.scheduler.manager [None req-c67986fa-2e3b-45b7-96dd-196704945b95
admin admin] *Starting to schedule for instances:
[u'8b227e85-8959-4e07-be3d-1bc094c115c1']* {{(pid=23795)
select_destinations
/opt/stack/new/nova/nova/scheduler/manager.py:118}}May 06
09:41:23.969293

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
oslo_concurrency.lockutils [None
req-c67986fa-2e3b-45b7-96dd-196704945b95 admin admin] Lock
"placement_client" acquired by
"nova.scheduler.client.report._create_client" :: waited 0.000s
{{(pid=23795) inner
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:273}}May
06 09:41:23.975304

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
oslo_concurrency.lockutils [None
req-c67986fa-2e3b-45b7-96dd-196704945b95 admin admin] Lock
"placement_client" released by
"nova.scheduler.client.report._create_client" :: held 0.006s
{{(pid=23795) inner
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:285}}May
06 09:41:24.276470

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
oslo_concurrency.lockutils [None
req-c67986fa-2e3b-45b7-96dd-196704945b95 admin admin] Lock
"6e118c71-9008-4694-8aee-faa607944c5f" acquired by
"nova.context.get_or_set_cached_cell_and_set_connections" :: waited
0.000s {{(pid=23795) inner
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:273}}May
06 09:41:24.279331

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
oslo_concurrency.lockutils [None
req-c67986fa-2e3b-45b7-96dd-196704945b95 admin admin] Lock
"6e118c71-9008-4694-8aee-faa607944c5f" released by
"nova.context.get_or_set_cached_cell_and_set_connections" :: held
0.003s {{(pid=23795) inner
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:285}}May
06 09:41:24.302854

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
oslo_db.sqlalchemy.engines [None
req-c67986fa-2e3b-45b7-96dd-196704945b95 admin admin] MySQL server
mode set to 
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
{{(pid=23795) _check_effective_sql_mode
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py:308}}May
06 09:41:24.321713

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
nova.filters [None req-c67986fa-2e3b-45b7-96dd-196704945b95 admin
admin] *Starting with 0 host(s)* {{(pid=23795) get_filtered_objects
/opt/stack/new/nova/nova/filters.py:70}}May 06 09:41:24.322136

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: INFO
nova.filters [None req-c67986fa-2e3b-45b7-96dd-196704945b95 admin
admin] Filter RetryFilter returned 0 hostsMay 06 09:41:24.322614

ubuntu-xenial-inap-mtl01-0003885152 nova-scheduler[21962]: DEBUG
nova.filters [None req-c67986fa-2e3b-45b7-96dd-196704945b95 admin
admin] Filtering removed all hosts for the request with instance ID
'8b227e85-8959-4e07-be3d-1bc094c115c1'.

[openstack-dev] [tricircle] Nominate change in tricircle core team

[Vega Cai]

Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle
core reviewer. Baisen has actively joined the discussion of feature
development and has contributed important patches since Queens, like
resource deletion reliability and openstack-sdk new version adaption. I
really think his experience will help us substantially improve tricircle.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Rocky Tricircle PTL candidacy

[Vega Cai]

Hi folks,

I would like to announce my self nomination for the PTL candidacy in
Tricircle Rocky cycle. My name is Zhiyuan Cai, and my IRC handle is
zhiyuan. I am currently the PTL of Tricircle for Queens cycle and have been
actively participating in the development of this project since Mitaka
cycle.

During the Queens cycle, we begin to bring QoS and LBaas support to
Tricircle, test scenario coverage is improved in our smoke test, we also
start to solve the resource deletion reliability problem and have figured
out a solution.

For the coming Rocky cycle, here are some works we can focus on:

* The QoS and LBaas features are not fully supported in Queens cycle so we
can improve them in Rocky cycle.
* Implement the new cross-Neutron L3 networking model that doesn't depend
on host routes.
* Finish the resource deletion reliability solution.

Hope everyone will enjoy running and developing Tricircle.

Thank you for your kind consideration of my candidacy.

BR
Zhiyuan Cai
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] No Tricircle meeting tomorrow

[Vega Cai]

Hi,

Tomorrow I will attend the bug smash in Wuhan so I will not be able to
chair the weekly meeting. We will resume the meeting next week.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]Distinguish the direction of requests

[Vega Cai]

For the first question, since api-paste.ini is a configuration file, you
can just add your new filter to the configuration file so your filter can
take effect. As Joe suggests, you can add embed the information in the
oslo.context object so plugin can get it from context which is passed to
plugin.

On Fri, 3 Nov 2017 at 12:29 joehuang  wrote:

> Hello,
>
> As you are talking about how to distinguish the request to local Neutron
> and central Neutron, do you mean how to set the "USER_AGENT" in the request
> header, and how to extract the "USER_AGENT" and stored it in the context?
> Though it's mentioned in
> https://developer.openstack.org/sdks/python/openstacksdk/users/connection.html
>
> This field has not been extracted neither in oslo.context, nor neutron-lib
> context:
>
>
> https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py
> https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py
>
>
> May be we can add it in oslo.context?
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *From:* XuZhuang [xu_ly...@163.com]
> *Sent:* 01 November 2017 19:49
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [tricircle]Distinguish the direction of
> requests
>
> Hello,
>
> I have some questions in how to distinguish the direction of requests
> between local neutron and central neutron.
>
>
> There is the preliminary plan
>
>
> 1. For how to distinguish the requests in central neutron
>
> we can add a filter in neutron/…./etc/api-paste.ini. Using this filter we
> can get some values about the source.
>
> But the question is that the process of loading filter is in Neutron.
> Without changing Neutron how could we add a filter? Could we change Neutron?
>
>
> 2. For how to add a signal in the requests
>
> The module of common.client in Tricircle is responsible for sending
> requests. So we can add a signal in the header of requests. And central
> plugin will get this signal using the filter.
>
>
> Best Regards
>
> Zhuangzhuang Xu (Lyman Xu)
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Update on Zuul v3 Migration - and what to do about issues

[Vega Cai]

Hi Mohammed,

Thanks for your suggestion. I have submitted a patch [1] to try to fix the
job configuration, and used [2] that depends on it to test whether the fix
works.

[1] https://review.openstack.org/#/c/508824/
[2] https://review.openstack.org/#/c/508496/

On Sat, 30 Sep 2017 at 20:31 Mohammed Naser  wrote:

> Hi Vega,
>
> Please check the document. Some jobs were migrated with incorrect nodesets
> and have to be switched to multinode in the job definition in
> openstack-zuul-jobs
>
> Good luck
> Mohammed
>
> Sent from my iPhone
>
> On Sep 30, 2017, at 7:35 AM, Vega Cai  wrote:
>
> Hi,
>
> In Tricircle we use the "multinode" topology to setup a test environment
> with three regions, "CentralRegion" and "RegionOne" in one node, and
> "RegionTwo" in the other node. I notice that the job definition has been
> migrated to
> openstack-zuul-jobs/blob/master/playbooks/legacy/tricircle-dsvm-multiregion/run.yaml,
> but the job fails with the error that "public endpoint for image service in
> RegionTwo region not found", so I guess the node of "RegionTwo" is not
> correctly running. Since the original log folder for the second
> "subnode-2/" is missing in the job report, I also cannot figure out what
> the wrong is with the second node.
>
> Any hints to debug this problem?
>
>
> On Fri, 29 Sep 2017 at 22:59 Monty Taylor  wrote:
>
>> Hey everybody!
>>
>> tl;dr - If you're having issues with your jobs, check the FAQ, this
>> email and followups on this thread for mentions of them. If it's an
>> issue with your job and you can spot it (bad config) just submit a patch
>> with topic 'zuulv3'. If it's bigger/weirder/you don't know - we'd like
>> to ask that you send a follow up email to this thread so that we can
>> ensure we've got them all and so that others can see it too.
>>
>> ** Zuul v3 Migration Status **
>>
>> If you haven't noticed the Zuul v3 migration - awesome, that means it's
>> working perfectly for you.
>>
>> If you have - sorry for the disruption. It turns out we have a REALLY
>> complicated array of job content you've all created. Hopefully the pain
>> of the moment will be offset by the ability for you to all take direct
>> ownership of your awesome content... so bear with us, your patience is
>> appreciated.
>>
>> If you find yourself with some extra time on your hands while you wait
>> on something, you may find it helpful to read:
>>
>>https://docs.openstack.org/infra/manual/zuulv3.html
>>
>> We're adding content to it as issues arise. Unfortunately, one of the
>> issues is that the infra manual publication job stopped working.
>>
>> While the infra manual publication is being fixed, we're collecting FAQ
>> content for it in an etherpad:
>>
>>https://etherpad.openstack.org/p/zuulv3-migration-faq
>>
>> If you have a job issue, check it first to see if we've got an entry for
>> it. Once manual publication is fixed, we'll update the etherpad to point
>> to the FAQ section of the manual.
>>
>> ** Global Issues **
>>
>> There are a number of outstanding issues that are being worked. As of
>> right now, there are a few major/systemic ones that we're looking in to
>> that are worth noting:
>>
>> * Zuul Stalls
>>
>> If you say to yourself "zuul doesn't seem to be doing anything, did I do
>> something wrong?", we're having an issue that jeblair and Shrews are
>> currently tracking down with intermittent connection issues in the
>> backend plumbing.
>>
>> When it happens it's an across the board issue, so fixing it is our
>> number one priority.
>>
>> * Incorrect node type
>>
>> We've got reports of things running on trusty that should be running on
>> xenial. The job definitions look correct, so this is also under
>> investigation.
>>
>> * Multinode jobs having POST FAILURE
>>
>> There is a bug in the log collection trying to collect from all nodes
>> while the old jobs were designed to only collect from the 'primary'.
>> Patches are up to fix this and should be fixed soon.
>>
>> * Branch Exclusions being ignored
>>
>> This has been reported and its cause is currently unknown.
>>
>> Thank you all again for your patience! This is a giant rollout with a
>> bunch of changes in it, so we really do appreciate everyone's
>> understanding as we work through it all.
>>
>> Monty
>

Re: [openstack-dev] [all] Update on Zuul v3 Migration - and what to do about issues

[Vega Cai]

Hi,

In Tricircle we use the "multinode" topology to setup a test environment
with three regions, "CentralRegion" and "RegionOne" in one node, and
"RegionTwo" in the other node. I notice that the job definition has been
migrated to
openstack-zuul-jobs/blob/master/playbooks/legacy/tricircle-dsvm-multiregion/run.yaml,
but the job fails with the error that "public endpoint for image service in
RegionTwo region not found", so I guess the node of "RegionTwo" is not
correctly running. Since the original log folder for the second
"subnode-2/" is missing in the job report, I also cannot figure out what
the wrong is with the second node.

Any hints to debug this problem?


On Fri, 29 Sep 2017 at 22:59 Monty Taylor  wrote:

> Hey everybody!
>
> tl;dr - If you're having issues with your jobs, check the FAQ, this
> email and followups on this thread for mentions of them. If it's an
> issue with your job and you can spot it (bad config) just submit a patch
> with topic 'zuulv3'. If it's bigger/weirder/you don't know - we'd like
> to ask that you send a follow up email to this thread so that we can
> ensure we've got them all and so that others can see it too.
>
> ** Zuul v3 Migration Status **
>
> If you haven't noticed the Zuul v3 migration - awesome, that means it's
> working perfectly for you.
>
> If you have - sorry for the disruption. It turns out we have a REALLY
> complicated array of job content you've all created. Hopefully the pain
> of the moment will be offset by the ability for you to all take direct
> ownership of your awesome content... so bear with us, your patience is
> appreciated.
>
> If you find yourself with some extra time on your hands while you wait
> on something, you may find it helpful to read:
>
>https://docs.openstack.org/infra/manual/zuulv3.html
>
> We're adding content to it as issues arise. Unfortunately, one of the
> issues is that the infra manual publication job stopped working.
>
> While the infra manual publication is being fixed, we're collecting FAQ
> content for it in an etherpad:
>
>https://etherpad.openstack.org/p/zuulv3-migration-faq
>
> If you have a job issue, check it first to see if we've got an entry for
> it. Once manual publication is fixed, we'll update the etherpad to point
> to the FAQ section of the manual.
>
> ** Global Issues **
>
> There are a number of outstanding issues that are being worked. As of
> right now, there are a few major/systemic ones that we're looking in to
> that are worth noting:
>
> * Zuul Stalls
>
> If you say to yourself "zuul doesn't seem to be doing anything, did I do
> something wrong?", we're having an issue that jeblair and Shrews are
> currently tracking down with intermittent connection issues in the
> backend plumbing.
>
> When it happens it's an across the board issue, so fixing it is our
> number one priority.
>
> * Incorrect node type
>
> We've got reports of things running on trusty that should be running on
> xenial. The job definitions look correct, so this is also under
> investigation.
>
> * Multinode jobs having POST FAILURE
>
> There is a bug in the log collection trying to collect from all nodes
> while the old jobs were designed to only collect from the 'primary'.
> Patches are up to fix this and should be fixed soon.
>
> * Branch Exclusions being ignored
>
> This has been reported and its cause is currently unknown.
>
> Thank you all again for your patience! This is a giant rollout with a
> bunch of changes in it, so we really do appreciate everyone's
> understanding as we work through it all.
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] PTG summary

[Vega Cai]

Hello folks,

After the discussion in the PTG on last Friday, we plan the following work
items for the Queens circle:

queens-1
LBaaS
Integration with Nova cell V2
Distinguish request from user and local neutron server
Default security group update

queens-2
Network deletion reliability
Security group delete
QoS

queens-3
Support new cross-neutron l3 networking model
Smoke test improvement

Please refer to the etherpad page[1] for details.

[1] https://etherpad.openstack.org/p/tricircle-queens-ptg

BR
Zhiyuan

-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] [ptg] PTG reminder

[Vega Cai]

Hello folks,

Just to remind that the PTG of Tricircle team will be held on Sep 15th,
from 9:00 am to 17:00 pm(UTC+8). We will discuss our topics in this
etherpad page[1] and #openstack-tricircle channel, so you can join the
discussion via etherpad and IRC. Also, please feel free to add topic to the
etherpad page.

[1] https://etherpad.openstack.org/p/tricircle-queens-ptg

BR
Zhiyuan Cai

-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Tricircle PTG plan

[Vega Cai]

Hello folks,

As discussed in our weekly meeting, since most of our developers are in
China, we will hold a small scale team gathering in China. Please refer to
this etherpad page[1] for the date and place of the gathering. During the
gathering, we will discuss our topics in that etherpad page and
#openstack-tricircle channel, so for those who cannot attend the gathering
but would like to follow the discussion, you can join via etherpad and IRC.
Also, please feel free to add topic to the etherpad page.

[1] https://etherpad.openstack.org/p/tricircle-queens-ptg

BR
Zhiyuan

-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle-Problem accessing the instance console]

[Vega Cai]

Hi Meher,

You can first check whether the nova-consoleauth and nova-novncproxy
services are correctly running. If you use DevStack, the window names for
these two services are n-cauth and n-novnc.

BR
Zhiyuan

On Wed, 23 Aug 2017 at 23:55  wrote:

> Hello to the Tricircle community,
>
>
>
> I am sending you this mail in order to ask for help concerning the launch
> of the console of the instances created in the different regions.
>
>
>
> I have two regions each with an active instance and its status is
> "running", for the first region, I can not open the console from the
> dashboard and for the second, the console is displayed but with an error of
> connection to the server.
>
> PS: access to both console worked without problems before I restarted my
> server.
>
>
>
> Thank you in advance for your help.
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> (+33) 7 58 38 68 87 <+33%207%2058%2038%2068%2087>
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WTC/CMA/MAX
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle-North South Networking via Direct Provider Networks]

[Vega Cai]

Also, you can upload a new image with OpenStack client, when horizon
service is not running:

https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/image.html#image-create

Since Nova service is running on RegionOne and RegionTwo, the image should
be also uploaded to RegionOne and RegionTwo, by specifying --os-region-name
for the command.

BR
Zhiyuan

On Sat, 19 Aug 2017 at 21:56 joehuang  wrote:

> Hello, Meher,
>
> By default, only one nic will come up for the
> instance from cirros image.
>
> You can log into the instance, follow this mail thread to bring up
> the second nic.
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-October/048574.html
>
> Best Regards
> Chaoyi Huang(joehuang)
> *发件人：*meher.h...@orange.com
> *收件人：*openstack-dev
> *时间：*2017-08-18 23:30:01
> *主题:*[openstack-dev] [tricircle-North South Networking via Direct
> Provider Networks]
>
> Hello everyone,
>
>
>
> Still in the test phase of the scenarios proposed by the Tricircle
> documentation, I try to do "North South Networking via Direct Provider
> Networks" but I failed to start an instance with 2 NICs, apparently the
> Cirros image does not support this option by default.
>
>
>
> So I will add a new image and so I need the horizon service which is
> disabled when installing Tricircle. Thanks in advance for giving me an idea
> on how to add the dashboard without re-deploying!
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WTC/CMA/MAX
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle-Service Function Chaining]

[Vega Cai]

Hi Meher,

The document structure of networking-sfc has been changed so the link in
the guide is not accurate. Since you have already deployed Tricircle and
would like to enable service function chaining feature, I think you can
refer to these guides[1, 2] to setup local Neutron server. The
configuration for local Neutron server is /etc/neutron/neutron.conf
and /etc/neutron/plugins/ml2/ml2_conf.ini for the DevStack setup. And
/etc/neutron/neutron.conf.0 is the configuration file for central Neutron
server.

BTW, would you like to join our weekly meeting? The current time(9:00 am
UTC+8 on Wednesday) may not be suitable for you, but we can figure out a
proper time and rearrange the meeting.

[1] https://docs.openstack.org/networking-sfc/latest/install/install.html
[2]
https://docs.openstack.org/networking-sfc/latest/install/configuration.html

BR
Zhiyuan

On Thu, 17 Aug 2017 at 18:10  wrote:

> Hello to all the community of Tricircle,
>
>
>
> I deployed Tricircle according to the architecture proposed by "Multi-pod
> Installation with DevStack". Now I'm trying to apply the "Networking Guide"
> tutorial and more specifically "Service Function Chaining Guide". Indeed, I
> find that the configuration is somewhat ambiguous with regard to the
> configuration of local neutron.
>
>
>
> I thank you in advance for helping me on this by a more detailed
> explanation. Have a great day!
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WTC/CMA/MAX
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tricircle] Queens PTL candidacy

[Vega Cai]

Hi all,

I would like to announce my self nomination for the PTL candidacy in
Tricircle Queens cycle. My name is Zhiyuan Cai, and my IRC handle is
zhiyuan. As a core reviewer of Tricircle project, I have been actively
participating in the development of this project since Mitaka cycle.

During the Pike cycle, many fancy features are brought to Tricircle, like
VxLAN support for cross Neutron L2/L3 networking, VLAN aware VMs, service
function chaining; reliability and performance are improved for the
asynchronous job running daemon; multi-region gate job is set up to test
Tricircle in a real running OpenStack environment, a YAML based task schema
is introduced to help developers to define the test scenario more easily.

For the coming Queens cycle, here are some works we can focus on:

* Continue the development of advanced networking features, like QoS and
LBaaS.
* Improve the test scenario coverage of multi-region gate job.
* Examine the integration with Nova cell V2.

Hope everyone will enjoy running and developing Tricircle.

Thank you for your kind consideration of my candidacy.

Best Regards
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]

[Vega Cai]

Hi Meher,

According to the DevStack script, for RHEL, the Apache configuration files
are placed in /etc/httpd/conf.d

BR
Zhiyuan

On Mon, 10 Jul 2017 at 22:14  wrote:

> Hello everybody,
>
>
>
> I posted before a problem related to installing the tricircle on a single
> node, the script stopped with a keystone startup. You advised me to see the
> / etc / apache2 / sites-enabled folder to see if the keystone config files
> are included. But, I have not found this folder, yet the httpd service is
> properly installed, the name of this file changes according to the
> distribution? I use RHEL 7, thank you in advance!
>
>
>
> Meher
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WTC/CMA/MAX
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> *De :* HIHI Meher IMT/OLN
> *Envoyé :* mercredi 28 juin 2017 15:12
> *À :* 'openstack-dev@lists.openstack.org'
> *Objet :* [openstack-dev][tricircle]
>
>
>
> Hello everyone,
>
>
>
> I introduce myself; Meher Hihi; I am doing my internship at Orange Labs
> Networks Lannion-France for the diploma of computer network and
> telecommunications engineer.
>
>
>
> I am working on innovative distribution solutions for the virtualization
> infrastructure of the network functions and more specifically on the
> Openstack Tricircle solution, which is why I join your community to
> participate in your discussions and learn from your advice.
>
>
>
> Indeed, I try to install Tricircle on a single node by following this
> documentation “
> https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack
> ”.
>
> I managed to install Devstack without any problems, but when I modify the
> local.conf file by adding the Tricircle plugin integration and the HOST_IP,
> the script does not want to work and stops on an error of Start of the
> Keystone service.
>
>
>
> I wanted to know if the problem is with my config file that is attached or
> I lack other things to configure. You will also find in the file the IP
> address of the machine.
>
>
>
> I thank you in advance for the help you will bring me. Sincerely,
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WNI/ODIS/NAVI
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]

[Vega Cai]

Hi Meher,

Welcome to join Tricircle!

Both Keystone and Tricircle services are running under Apache, so if
Keystone failed to start after enabling Tricircle, I guess there might be
some problems of Apache configuration. You can check what services are
enabled in Apache by listing this folder: /etc/apache2/sites-enabled.

tricircle@zhiyuan-1:~/devstack$ ls /etc/apache2/sites-enabled/
keystone-wsgi-admin.conf  keystone-wsgi-public.conf
 nova-placement-api.conf  tricircle-api.conf

Above is the result from my Ubuntu machine.

Also, could you provide me the log of DevStack after enabling Tricircle so
I can get more hints.

BR
Zhiyuan

On Wed, 28 Jun 2017 at 21:17  wrote:

> Hello everyone,
>
>
>
> I introduce myself; Meher Hihi; I am doing my internship at Orange Labs
> Networks Lannion-France for the diploma of computer network and
> telecommunications engineer.
>
>
>
> I am working on innovative distribution solutions for the virtualization
> infrastructure of the network functions and more specifically on the
> Openstack Tricircle solution, which is why I join your community to
> participate in your discussions and learn from your advice.
>
>
>
> Indeed, I try to install Tricircle on a single node by following this
> documentation “
> https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack
> ”.
>
> I managed to install Devstack without any problems, but when I modify the
> local.conf file by adding the Tricircle plugin integration and the HOST_IP,
> the script does not want to work and stops on an error of Start of the
> Keystone service.
>
>
>
> I wanted to know if the problem is with my config file that is attached or
> I lack other things to configure. You will also find in the file the IP
> address of the machine.
>
>
>
> I thank you in advance for the help you will bring me. Sincerely,
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WNI/ODIS/NAVI
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]mascot for the Tricircle project

[Vega Cai]

So cute XD

Zhiyuan

On Mon, 24 Apr 2017 at 16:11 Zhipeng Huang  wrote:

> perfect XD
>
> On Mon, Apr 24, 2017 at 2:59 PM, joehuang  wrote:
>
>> Hello, team,
>>
>> What about the mascot of Tricircle project?
>>
>> Your comments are welcome.
>>
>> Best Regards
>> Chaoyi Huang(joehuang)
>>
>>
>> *From:* Heidi Joy Tretheway [heidi...@openstack.org]
>> *Sent:* 22 April 2017 6:15
>> *To:* joehuang
>> *Subject:* Re: Question about the Tricircle mascot
>>
>> Hi Joe,
>> Following up on your team’s mascot request, our illustrators came back
>> with a beautiful piece. Would you please let me know what your team thinks?
>>
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

[Vega Cai]

+1

Zhiyuan

On Wed, 1 Mar 2017 at 11:41 Devale, Sindhu  wrote:

> +1
>
> Sindhu
>
> From: joehuang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, February 28, 2017 at 8:38 PM
> To: openstack-dev 
> Subject: [openstack-dev] [tricircle]Nominating Victor Morales as
> Tricircle Core
>
> Hi Team,
>
> Victor Morales has made many review contributions[1] to Trircircle since
> the Ocata cycle, and he also created the python-tricircleclient
> sub-project[2]. I would like to nominate him to be Tricircle core
> reviewer. I really think his experience will help us substantially
> improve Trircircle.
>
>  It's now time to vote :)
>
> [1] http://stackalytics.com/report/contribution/tricircle/120
> [2] https://git.openstack.org/cgit/openstack/python-tricircleclient/
>
>
> Best Regards
> Chaoyi Huang (joehuang)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle][all] guide for reading source code

[Vega Cai]

Wow, awesome guide!!

My suggestion will be no matter where we maintain the guide, it will be
better to not just update the original guide directly, to make readers easy
to follow the changes of logic.

BR
Zhiyuan

On Tue, 21 Feb 2017 at 11:00 joehuang  wrote:

> Hello,
>
> For those who are interested in digging into Tricircle source code, it'll
> be good to have a step by step guide. I prepared a wiki page to navigate
> the source code of Tricircle:
>
> https://wiki.openstack.org/wiki/TricircleHowToReadCode
>
> It was linked to the wiki page of Tricircle:
> https://wiki.openstack.org/wiki/Tricircle
>
> And also please feel free to update the wiki to make it being more
> readable and consistent with the code.
>
> Should we include it into the source code repo, and maintain it at the
> same time if we update the code logic?
>
> Best Regards
> Chaoyi Huang (joehuang)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [devstack] [tricircle] Problem in placement-api after installing Tricircle with DevStack

[Vega Cai]

In Nova Ocata release, deploying placement API is a must. The nova-compute
service will fail to start if [placement] section is not configured in
nova.conf.

DevStack script is updated to generate Apache configuration file for
placement API and it works fine in single region scenario.

However, in Tricircle, we will have multi-region deployment: one node runs
Keystone, Tricircle and other core services(like Nova, Neutron, Cinder),
another node just runs core services and we configure these services to
talk to Keystone in the first node. After updating codes to the newest
version, we find that we fail to boot an instance in the second node.

After digging into the log files, we find the reason is that, the placement
API Apache configuration file generated by DevStack doesn't grant necessary
access right to the placement API bin folder. In the first node where
Keystone is running, Apache configuration file for Keystone already grants
access right to "/usr/local/bin" folder, and this folder happens to be the
same folder placement API bin is located, so placement API works fine. But
in the second node, Keystone is not enabled, so request sent to placement
API is rejected and thus we fail to boot an instance.

One temporary workaround is to manually edit placement API configuration
file in the second node to add the following section:


Require all granted


and restart Apache. We test and it works. Later we are going to submit a
patch to DevStack for this problem.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tricircle] Heading for PTG

[Vega Cai]

Hi folks,

I am heading for Atlanta PTG as the representative of Tricircle project, if
you are interested in Tricircle project and will also attend Atlanta PTG,
we can meet and discuss some topics there.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Barcelona summit "neutron-agent retrospective" recap

[Vega Cai]

It's cool to store tunnel termination endpoint information in the port
model. Will this information support updating so external devices or
controllers can inject the tunnel termination endpoints via the API? This
is very useful to support VxLAN type external network, which there are
already some patches working on it[1,2].

[1] https://review.openstack.org/#/c/282180
[2] https://review.openstack.org/#/c/317309

BR
Zhiyuan

On Thu, 10 Nov 2016 at 04:31 Kevin Benton  wrote:

> There were three main topics discussed during the neutron-agent
> retrospective session: deprecating the CLI OVS interfaces, refactoring the
> agent to use the callback framework, and eliminating the L2pop driver.
>
> Deprecating the CLI OVS Interfaces
> 
> We now have native replacements for shelling out to ovs-vsctl and
> ovs-ofctl using a python ovsdb interface and the RYU openflow code,
> respectively. Currently, it's an operator configuration option to choose
> the native vs legacy interfaces. The native interfaces were the default for
> the last cycle, so we would like to deprecate the legacy interfaces and
> remove them in Pike.
>
> This appeared to have general consensus, contingent on fixing a few parity
> bugs with the CLI interface for handling flows. If using the CLI interfaces
> is critical to a use case, please reply to this email because we will
> proceed with the deprecation otherwise.
>
> Refactoring the agent to use the callback framework
> --
> We need to refactor some of the main OVS agent file to make it more
> maintainable. The file itself contains over 2000 lines of python and the
> methods are insanely long and complex, making unit testing difficult and
> questionable in its efficacy. This makes adding new features scary, which
> slows down development.
>
> While there was nobody against refactoring the agent, we decided to defer
> this work due to the short nature of this cycle and the potential conflicts
> it will have with the next bullet point.
>
> However, any refactoring required for other development activities
> (features or fixes), will not be blocked.
>
> Eliminating L2pop as a mechanism driver
> 
> L2pop calculates information on the fly to determine tunnel termination
> endpoints. This is racey (out of order tunnel notifications are not
> handled) and leads to lots of complexity involving lookups to agent tables,
> etc. This also makes it very difficult to integrate external devices
> because they have no way of informing the agents of their tunnel
> termination endpoint.
>
> We'd like to formalize the tunnel termination point by adding it to the
> port binding data model just like other encapsulation details (bound
> segment, segmentation id, etc). This will allow mech drivers to bind ports
> not based on agents and allow seamless integration with agent-based ports.
> The L2pop server-side logic would go away since agents would setup
> forwarding entries just based on the latest data on the port models
> delivered via push notifications.
>
> This will require some changes on the server side in the port binding
> process to have the mech drivers provide the tunnel termination point as
> part of the binding details. The agent side will also require a few changes
> to have its tunnel forming logic be derived from push notifications instead
> of tunnel and fdb notifications.
>
> This change will likely need a small spec to scope out the new port
> binding process.
>
> Cheers,
> Kevin Benton
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Feature to enhance floating IP router lookup to consider extra routes

[Vega Cai]

Hi folks,

During the development of Tricircle, we find that one feature whose spec
has already been accepted is very useful, that is to enhance floating IP
router lookup to consider extra routes[1]. With this feature, floating IP
is allowed to be associated to internal addresses that are reachable by
routes over intermediate networks. However the implementation patch has
been abandoned since the owner didn't update the patch for a long time[2].

We would like to continue to work on it. Shall we just restore the patch or
a new RFE patch is needed?

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/juno/floating-ip-extra-route.html
[2] https://review.openstack.org/#/c/55987
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]Tricricle cleanning

[Vega Cai]

Hello, patch for installation guide update of multi-node deployment has
just been submitted.  Here is the link:
https://review.openstack.org/#/c/385306/

BR
Zhiyuan

On Wed, 12 Oct 2016 at 10:17 joehuang  wrote:

> Hello, Team,
>
> Understand this period is keeping us quite busy, for the Tricircle
> cleaning is in parallel with newton release period. Fortunately we have
> made great progress for the Tricircle cleaning and Newton release is
> approaching completeness.
>
> (https://etherpad.openstack.org/p/TricircleSplitting)
>
>
>- DONE 1. update README: https://review.openstack.org/#/c/375218/
>
>
>- DONE 1. local plugin spec: https://review.openstack.org/#/c/368529/
>
>
>- DONE 1. local and central plugin:
>https://review.openstack.org/#/c/375281/
>
>
>-
>- 2.central and local plugin for l3:
>https://review.openstack.org/#/c/378476/
>
>
>- 2. remove api gateway code: https://review.openstack.org/#/c/384182/
>
>
>- 3.  security group support: https://review.openstack.org/#/c/380054/
>
>
>- 3. installation guide update(no api gateway):
>
>
>- Part1: Single Node installation:
>https://review.openstack.org/#/c/384872/
>
>
>- Part2: Multi nodes installation: WIP
>
>
>-
>
>
>- - Try to get these above cleaning patches merged before Oct.19,
>before Barcelona summit.
>
>
>
>
> Except the patch " Multi nodes installation", all other patches are in
> the queue of review for the Tricircle cleaning. After these patches get
> merged, we can have a first clean Tricircle baseline for networking
> automation, it's good to have a tagging for this baseline as a milestone.
>
> Best Regards
> Chaoyi Huang (joehuang)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]freeze date and tricircle splitting

[Vega Cai]

Since the patches for layer 3 networking automation has been merged, I
think we'd better include the patches for resource cleaning in the tagged
branch. Here is the list:

Floating ip deletion: https://review.openstack.org/354604
Subnet cleaning: https://review.openstack.org/355847
Router cleaning: https://review.openstack.org/360848

Shinobu Kinjo 于2016年9月20日周二 下午12:04写道：

> This announcement should have been first to avoid any unnecessary work -;
>
> On Tue, Sep 20, 2016 at 12:51 PM, joehuang  wrote:
> > Hello, as the Trio2o repository has been established, it's time for us to
> > discuss the freeze date and tagging(newton branch) for the last release
> of
> > Tricircle with gateway function.
> >
> > The freeze date is the gate for patches to be merged before
> tagging(newton
> > branch). If a patch can't finish review process before the freeze date,
> and
> > not able to be merged in Tricircle, then it's suggested to be handled
> like
> > this:
> >
> > 1. If it's networking automation related patch, continue the review
> process
> > in Tricircle after tagging(newton branch), will be merged in Tricircle
> trunk
> > in the future .
> >
> > 2. If it's gateway related patch, abandon the patch, re-submit the patch
> in
> > Trio2o.
> >
> > 3. If it's patch about pod management, for it's common feature, so
> continue
> > the review process in tricircle  after tagging(newton branch) , and
> submit a
> > new patch for this feature in Trio2o separately.
> >
> > Exception request after freeze date, before tagging(newton branch): If
> there
> > is some patch must be merged before the tagging(newton branch), then
> need to
> > send the exception request in the mail-list for the patch, and approved
> by
> > PTL.
> >
> > That means we need to define a deadline for patches to be merged in
> > Tricircle before tagging(newton branch), and define the scope of patches
> > wish to be merged in Trcircle before splitting.
> >
> > Your thoughts, proposal for the freeze date and patches to be merged?
> >
> > (As the old thread containing both Trio2o and Tricircle in the subject,
> not
> > good to follow, so a new thread is started)
> >
> > Best Regards
> > Chaoyi Huang (joehuang)
> >
> > 
> > From: joehuang
> > Sent: 18 September 2016 16:34
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: RE: [openstack-dev] [tricircle][trio2o] trio2o git repo ready
> and
> > tricircle splitting
> >
> > Thank you for your comment, Zhiyuan.
> >
> > For pod management, because these two projects need to run
> independently, I
> > think submit patches separately as needed may be a better choice.
> >
> > Best Regards
> > Chaoyi Huang(joehuang)
> > 
> > From: Vega Cai [luckyveg...@gmail.com]
> > Sent: 18 September 2016 16:27
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready
> and
> > tricircle splitting
> >
> > +1 for the proposal. What about the codes for Pod operation? It seems
> that
> > both Tricircle and Trio2o need these codes. We submit patches to these
> two
> > projects separately?
> >
> > Zhiyuan
> >
> > joehuang 于2016年9月18日周日 下午4:17写道：
> >>
> >> hello, team,
> >>
> >> Trio2o git repository is ready now: https://github.com/openstack/trio2o
> >>
> >> The repository inherited all files and commit messages from Tricircle.
> >>
> >> It's now the time start to do the tricircle splitting: a blue print is
> >> registere for Tricircle cleaning:
> >>
> https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
> >> are lots of documentation work to do. Please review these doc in the BP,
> >> thanks.
> >>
> >> There are some proposal for patches during the splitting:
> >>
> >> 1. For patch which is already in review status, let's review it in
> >> Tricircle (no matter it's for Trio2o or Tricircle), after it's get
> merged,
> >> then port it to Trio2o. After all patches get merged, let's have a last
> tag
> >> for Tricircle to cover both gateway and networking automation function.
> Then
> >> the cleaning will be done in Tricircle to make Tricircle as a project
> for
> >> networking automati

Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and tricircle splitting

[Vega Cai]

+1 for the proposal. What about the codes for Pod operation? It seems that
both Tricircle and Trio2o need these codes. We submit patches to these two
projects separately?

Zhiyuan

joehuang 于2016年9月18日周日 下午4:17写道：

> hello, team,
>
> Trio2o git repository is ready now: https://github.com/openstack/trio2o
>
> The repository inherited all files and commit messages from Tricircle.
>
> It's now the time start to do the tricircle splitting: a blue print is
> registere for Tricircle cleaning:
> https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron
> .There are lots of documentation work to do. Please review these doc in
> the BP, thanks.
>
> There are some proposal for patches during the splitting:
>
> 1. For patch which is already in review status, let's review it in
> Tricircle (no matter it's for Trio2o or Tricircle), after it's get merged,
> then port it to Trio2o. After all patches get merged, let's have a last tag
> for Tricircle to cover both gateway and networking automation function.
> Then the cleaning will be done in Tricircle to make Tricircle as a project
> for networking automation only
> 2. For new patch which is only applicable to Trio2o, I propose that we
> submit such patches in Trio2o only, no need to submit in Tricircle.
>
> Would like to know your thoughts on the splitting.
>
> Best Regards
> Chaoyi Huang(joehuang)
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] your proposal for the name of networking and gateway sub-projects

[Vega Cai]

Oops, sorry for "triangel". Then what about "trio2o", openstack-to-openstack

Zhiyuan

Yipei Niu 于2016年9月5日周一 上午11:22写道：

> Trifennel +1
>
> Best regards,
> Yipei
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]your proposal for the name of networking and gateway sub-projects

[Vega Cai]

+1 for Triangel

On 2 September 2016 at 17:34, joehuang  wrote:

> After the discussion in the #openstack-tricircle channel, 3 candidates
> available now, please vote the name for the new sub-project for api-gateway
> functionality:
>
> 1. Triangel
> The Triangel are dolls that bring luck
> 2. Tridonut
> Three Donuts. Delicious food, often buy 3 get 1 free.
> 3. Trifennel
> Three Fennel. Fennel is highly prized for its licorice-like flavor and
> the myriad of health benefits it provides
>
> Best Regards
> Chaoyi Huang(joehuang)
>
>
> *From:* joehuang
> *Sent:* 02 September 2016 11:19
> *To:* openstack-dev; mord...@inaugust.com
> *Subject:* RE: [openstack-dev][tricircle]your proposal for the name of
> networking and gateway sub-projects
>
> I have some rough ideas about the name of gateway sub-project, for
> example, triangle, tridonut, tricookie etc, so that we can see that
> Tricircle and the new sub-project are like sibling in OpenStack. And they
> often will be listed closely in order.
>
> Your thoughts?
>
> Best Regards
> Chaoyi Huang(joehuang)
>
> --
> *From:* joehuang
> *Sent:* 02 September 2016 10:22
> *To:* openstack-dev; mord...@inaugust.com
> *Subject:* [openstack-dev][tricircle]your proposal for the name of
> networking and gateway sub-projects
>
> Hello,
>
> If we want to divide Tricircle into two sub-projects, your proposals for
> the name of sub-projects are welcome.
>
> Because the Tricircle is applying big-tent application, and the networking
> part will be remained in the Tricircle repository, and continue the
> big-tent application. So if we change the networking sub-project name from
> "Tricircle" to another one, we have to update a lots of places: from infra,
> to source code, to documentation, google docs, to wiki, etc, it's a huge
> work, and history background will also be lost, from this point of view, I
> proposal to remain current Tricircle repository name, but shrink the
> Tricircle scope to cross Neutron networking automation.
>
> And for gateway part, a new repository is required, new project name is
> more applicable, this is just my thoughts, would like to know your
> proposals.
>
> Best Regards
> Chaoyi Huang(joehuang)
>
> 
> From: joehuang
> Sent: 01 September 2016 9:02
> To: Monty Taylor; openstack-dev
> Subject: RE: [openstack-dev][tricircle]How to address TCs concerns in
> Tricircle big-tent application
>
> Hello, Monty,
>
> Thank you very much for your guide and encouragement, then let's move on
> this direction.
>
> Best regards
> Chaoyi Huang (joehuang)
> 
> From: Monty Taylor [mord...@inaugust.com]
> Sent: 01 September 2016 0:37
> To: joehuang; openstack-dev
> Subject: Re: [openstack-dev][tricircle]How to address TCs concerns in
> Tricircle big-tent application
>
> On 08/31/2016 02:16 AM, joehuang wrote:
> > Hello, team,
> >
> > During last weekly meeting, we discussed how to address TCs concerns in
> > Tricircle big-tent application. After the weekly meeting, the proposal
> > was co-prepared by our
> > contributors: https://docs.google.com/presentation/d/1kpVo5rsL6p_
> rq9TvkuczjommJSsisDiKJiurbhaQg7E
> >
> > The more doable way is to divide Tricircle into two independent and
> > decoupled projects, only one of the projects which deal with networking
> > automation will try to become an big-tent project, And Nova/Cinder
> > API-GW will be removed from the scope of big-tent project application,
> > and put them into another project:
> >
> > *TricircleNetworking:* Dedicated for cross Neutron networking automation
> > in multi-region OpenStack deployment, run without or with
> > TricircleGateway. Try to become big-tent project in the current
> > application of https://review.openstack.org/#/c/338796/.
>
> Great idea.
>
> > *TricircleGateway:* Dedicated to provide API gateway for those who need
> > single Nova/Cinder API endpoint in multi-region OpenStack deployment,
> > run without or with TricircleNetworking. Live as non-big-tent,
> > non-offical-openstack project, just like Tricircle toady’s status. And
> > not pursue big-tent only if the consensus can be achieved in OpenStack
> > community, including Arch WG and TCs, then decide how to get it on board
> > in OpenStack. A new repository is needed to be applied for this project.
> >
> >
> > And consider to remove some overlapping implementation in Nova/Cinder
> > API-GW for global objects like flavor, volume type, we can configure one
> > region as master region, all global objects like flavor, volume type,
> > server group, etc will be managed in the master Nova/Cinder service. In
> > Nova API-GW/Cinder API-GW, all requests for these global objects will be
> > forwarded to the master Nova/Cinder, then to get rid of any API
> > overlapping-implementation.
> >
> > More information, you can refer to the proposal draft
> > https://docs.google.com/presentation/d/1kpVo5rsL6p_
> rq9TvkuczjommJSsisDiKJiurbh

Re: [openstack-dev] [tricircle] About registering and loading a plugin

[Vega Cai]

Hi Yipei,

You can also refer to my network type driver implementation:

https://review.openstack.org/#/c/331638/

Type driver is registered in setup.cfg and loaded by code.

BR
Zhiyuan

On 27 June 2016 at 21:44, Yipei Niu  wrote:

> Dear all,
>
> Recently, I learn to name a plugin based on the doc
> http://docs.openstack.org/developer/stevedore/tutorial/naming.html#. I
> define a new entry_point for the plugin, then it fails. The console prompts
> "stevedore.exception.NoMatches: No 'net.nyp.formatter' driver found,
> looking for 'simple'". After setting a new entry_point with setuptools, why
> stevedore cannot find the driver based on the entry_point?
>
> Best regards,
> Yipei
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] Launch work group for cross-pod L2 networking feature

[Vega Cai]

Hi members,

Thanks for attending the work group meeting. Our discussion log can be
viewed here:

https://docs.google.com/document/d/15meGv7wL2ClWZMKd4BPN0Q3br-ac2JDmTvFPLOgUHt0/edit?usp=sharing

BR
Zhiyuan

On 24 May 2016 at 09:51, Yipei Niu  wrote:

> Hi, all,
>
> Since I have to attend the dissertation defense of my master degree on
> Wednesday morning, I cannot attend the group meeting. Sorry about that. If
> it is inconvenient to reschedule the meeting, I will keep online in
> #openstack-tricircle so as to receive the meeting log.
>
> Best regards,
> Yipei
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Launch work group for cross-pod L2 networking feature

[Vega Cai]

Hi members,

Sorry that it's a bit late to launch our cross-pod L2 networking work group
since I was attending OSCON last week.

What about having our first work group meeting on Wednesday 10am(Beijing
time UTC+8), in #openstack-tricircle channel?

Topics I think we can discuss:
(1) feature specification improvement
(2) shared VLAN solution WIP patch

BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]Proposing Shinobu Kinjo for Tricircle core reviewer

[Vega Cai]

+1, Shinobu has given me many suggestions in my patches.

On 4 May 2016 at 07:57, Zhipeng Huang  wrote:

> +1, still remember Shinobu getting started from basic concept of
> tricircle, and now becoming a maester of multisite openstack :)
>
> On Tue, May 3, 2016 at 9:03 PM, joehuang  wrote:
>
>> Hi,
>>
>> I would like to propose adding Shinobu Kinjo to the Tricircle core
>> reviewer team.
>>
>> Shinobu has been a highly valuable reviewer to Tricircle for the past few
>> months. His contribution covers each patch submitted, document, etherpad
>> discussion, and always give valueable, meaningful and helpful comment. His
>> review data could be found from http://stackalytics.com/ (but
>> unfortuantely something wrong in stackalytics temporary, tricircle is
>> missing in the project lists)
>>
>> I believe Shinobu will be a great addition to the Tricircle team.
>>
>> Please response with +1/-1. Thank you!
>>
>> Best Regards
>> Chaoyi Huang ( joehuang )
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Easy Way to Test Tricircle North-South L3 Networking

[Vega Cai]

Hi all,

Just would like to share a way to test Tricircle north-south L3 networking
without requiring the third interface.

In the Tricircle readme, it is said that you need to add an interface in
your host to br-ext bridge. One interface to access the host, one interface
for east-west networking and one interface for north-south networking, so
all together three interfaces are required.

What if your host only have two interfaces? Here is another deployment
choice.

First, change your external network type to flat type. If you are using the
DevStack script provided by Tricircle, do the following changes in node2
local.conf then run DevStack in node2.

(1) change Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS
from (network_vlan_ranges=bridge:2001:3000,extern:3001:4000)
to (network_vlan_ranges=bridge:2001:3000)
(since we going to use flat external network, no need to configure VLAN
range for extern)
(2) add PHYSICAL_NETWORK=extern
(3) keep OVS_BRIDGE_MAPPINGS=bridge:br-bridge,extern:br-ext

Second, specify flat type when creating external network.

curl -X POST http://127.0.0.1:9696/v2.0/networks
   -H "Content-Type: application/json" \
   -H "X-Auth-Token: $token" \
   -d '{"network": {"name": "ext-net", "admin_state_up": true,
"router:external": true, "provider:network_type": "flat",
"provider:physical_network": "extern", "availability_zone_hints":
["Pod2"]}}'

Third, configure IP address of br-ext.

sudo ifconfig br-ext 163.3.124.1 netmask 255.255.255.0

Here 163.3.124.1 is your external network gateway IP, set net mask
according to your CIDR.

After the above steps, you can access your VM via floating IP in node2.
Also your VM can ping the external gateway.

Would like your VM to access the Internet?(Of course node2 should be able
to access the Internet) Two more steps to follow:
(1) Enable packet forward in node2

sudo bash
echo 1 >/proc/sys/net/ipv4/ip_forward

(2) Configure SNAT in node2

sudo iptables -t nat -I POSTROUTING -s 163.3.124.0/24 -o eth1 -j SNAT
--to-source 10.250.201.21

163.3.124.0/24 is your external network CIDR, eth1 is the interface
associated with your default route in node2 and 10.250.201.21 is the IP of
eth1.

Hope this information helps.

BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tricircle] Asynchronous Job Management Patches

[Vega Cai]

Hi, I have submitted the second patch for asynchronous job management,
please help to review. Here is the link:
https://review.openstack.org/#/c/302110/

The first patch has been merged. Link for the first patch:
https://review.openstack.org/#/c/295729/

BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Vega Cai]

y",
> line 87, in handle_args
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mreturn func(*args, **kwargs)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/tricircle/tricircle/common/client.py",
> line 358, in create_resources
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mreturn handle.handle_create(cxt, resource, *args,
> **kwargs)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/opt/stack/tricircle/tricircle/common/resource_handle.py", line 149, in
> handle_create
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m*args, **kwargs)[resource]
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line
> 100, in with_params
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mret = self.function(instance, *args, **kwargs)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line
> 552, in create_network
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mreturn self.post(self.networks_path, body=body)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line
> 271, in post
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mheaders=headers, params=params)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line
> 206, in do_request
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mself._handle_fault_response(status_code, replybody)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line
> 182, in _handle_fault_response
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mexception_handler_v20(status_code, des_error_body)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line
> 69, in exception_handler_v20
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mstatus_code=status_code)
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mBadRequest: Invalid input for operation: 'None' is not an
> integer.
> ^[[01;31m2016-03-29 15:41:04.122 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m
> 2016-03-29 15:41:04.137 ^[[00;36mINFO neutron.wsgi
> [^[[01;36mreq-0180a3f5-e34c-4d4c-bd39-3c0c714b02de ^[[00;36madmin
> 685f8f37363f4467bead5a375e855ccd^[[00;36m] ^[[01;35m^[[00;36m192.168.56.101
> - - [29/Mar/2016 15:41:04] "PUT
> /v2.0/routers/999a46c9-8055-4514-82d6-81945f095bd6/add_router_interface.json
> HTTP/1.1" 500 383 1.574475^[[00
>
> I search solutions with google, but get little information. Sorry to
> trouble you guys.
>
> Best regards,
> Yipei
>
> On Tue, Mar 29, 2016 at 4:36 PM, Vega Cai  wrote:
>
>> Hi Yipei,
>>
>> Glad to hear that you can successfully boot VMs. So the problems are
>> caused by the incompatibility of the nova, neutron and devstack code trees
>> in your environment. Yeah, what you did is what I always do. When devstack
>> fails to start or has some troubles, find the reason then modify the
>> scripts.
>>
>> I am updating the code trees in my environment to the newest version to
>> see if tricircle can be correctly deployed. I will send out the result
>> later.
>>
>> BR
>> Zhiyuan
>>
>>
>> On 29 March 2016 at 16:10, Yipei Niu  wrote:
>>
>>> Hi, all,
>>>
>>> I follow the advice given by Zhiyuan, and it works. For the port error,
>>> somebody removes the line "iniset $NOVA_CONF DEFAULT network_api_class
>>> nova.network.neutronv2.api.API" in lib/neutron-legacy. For the unknown
>>> auth_plugin error in the first mail, somebody changes the auth_plugin to
>>> auth_type in lib/neutron-legacy, but the loader still searches auth_plugin
>>> for configuration in nova/network/neutronv2/api.py, which therefore leads
>>&g

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Vega Cai]

Hi Yipei,

Glad to hear that you can successfully boot VMs. So the problems are caused
by the incompatibility of the nova, neutron and devstack code trees in your
environment. Yeah, what you did is what I always do. When devstack fails to
start or has some troubles, find the reason then modify the scripts.

I am updating the code trees in my environment to the newest version to see
if tricircle can be correctly deployed. I will send out the result later.

BR
Zhiyuan


On 29 March 2016 at 16:10, Yipei Niu  wrote:

> Hi, all,
>
> I follow the advice given by Zhiyuan, and it works. For the port error,
> somebody removes the line "iniset $NOVA_CONF DEFAULT network_api_class
> nova.network.neutronv2.api.API" in lib/neutron-legacy. For the unknown
> auth_plugin error in the first mail, somebody changes the auth_plugin to
> auth_type in lib/neutron-legacy, but the loader still searches auth_plugin
> for configuration in nova/network/neutronv2/api.py, which therefore leads
> to none in auth_plugin option. I change the files to their original
> versions, respectively. Now I have booted two VMs successfully. Is the
> solution OK?
>
> BTW, I have some trouble with creating router and I am trying to fix it.
>
> Best regards,
> Yipei
>
> On Tue, Mar 29, 2016 at 2:25 PM, joehuang  wrote:
>
>> I think we can do it later. It's still a little bit strange that if
>> nova-network in the Local.conf is disabled at first before devstack
>> installation, the devstack should use Neutron instead, not sure how clean
>> Yipei's environment is.
>>
>> I suggest Yipei to use clean virtual machines running in virtualbox, and
>> follow the readme[1] and pengfei's experience[2] to install Tricircle.
>>
>> [1] https://github.com/openstack/tricircle/blob/master/README.md
>> [2] http://shipengfei92.cn/play_tricircle_with_virtualbox
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> Sent: Tuesday, March 29, 2016 10:48 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: Yipei Niu
>> Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node
>> configuration
>>
>> Sorry for interruption.
>>
>> >> I followed the README.md in github, every thing goes well until I
>> >> boot virtual machines with the following command
>>
>> Point here is that even Yipei was following READM provided by us, setting
>> up the tricircle was failed. [1] It may be required to review it, I think.
>>
>> [1] https://github.com/openstack/tricircle/blob/master/README.md
>>
>> Cheers,
>> Shinobu
>>
>>
>> On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai  wrote:
>> > Hi Yipei,
>> >
>> > If you want to use neutron, you need to set "nova_api_class" to
>> > "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
>> > network.
>> >
>> > Related code:
>> > https://github.com/openstack/nova/blob/master/nova/network/__init__.py
>> > #L47
>> >
>> > Simply search "Unknown argument: port" which is the error showed in
>> > the log in the nova code tree then you can find the above code.
>> >
>> > Also, if all the services are running but you want to change some of
>> > the configuration options, you can just modify the configuration files
>> > then restart the services, so you can quickly check if your
>> > modification works without restarting devstack.
>> >
>> > BR
>> > Zhiyuan
>> >
>> > On 29 March 2016 at 08:56, Yipei Niu  wrote:
>> >>
>> >> Hi, all,
>> >>
>> >> I checked nova.conf and local.conf both.
>> >>
>> >> In nova.conf, the option "nova_api_class" is missing while
>> "use_neutron"
>> >> is set as True. I modify the lib/nova so that the devstack can write
>> >> "nova_api_class=nova.network.api.API" to nova.conf [1]. However,
>> >> after installing devstack with tricircle, the same error still happens
>> as before.
>> >>
>> >> In local.conf, n-net is disabled, which is the same as the sample
>> >> file of tricircle.
>> >>
>> >> [1] http://docs.openstack.org/developer/nova/sample_config.html
>> >>
>> >> Best regards,
>> >> Yipei
>> >>
>> >> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
>> >> wrote:
>> >>

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Vega Cai]

Hi Yipei,

If you want to use neutron, you need to set "nova_api_class" to
"nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
network.

Related code:
https://github.com/openstack/nova/blob/master/nova/network/__init__.py#L47

Simply search "Unknown argument: port" which is the error showed in the log
in the nova code tree then you can find the above code.

Also, if all the services are running but you want to change some of the
configuration options, you can just modify the configuration files then
restart the services, so you can quickly check if your modification works
without restarting devstack.

BR
Zhiyuan

On 29 March 2016 at 08:56, Yipei Niu  wrote:

> Hi, all,
>
> I checked nova.conf and local.conf both.
>
> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
> is set as True. I modify the lib/nova so that the devstack can write
> "nova_api_class=nova.network.api.API" to nova.conf [1]. However, after
> installing devstack with tricircle, the same error still happens as before.
>
> In local.conf, n-net is disabled, which is the same as the sample file of
> tricircle.
>
> [1] http://docs.openstack.org/developer/nova/sample_config.html
>
> Best regards,
> Yipei
>
> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
> wrote:
>
>> FYI:
>> This is the reason is that there is still n-net. [1]
>>
>> [1]
>> http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
>>
>> Cheers,
>> S
>>
>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
>> > Hi,
>> >
>> >
>> >
>> > Agree, it’s quite important not to use Nova-network in devstack. In
>> devstack
>> > local.conf, make sure the Neutron service is enabled and Nova-network is
>> > disabled.
>> >
>> >
>> >
>> > # Use Neutron instead of nova-network
>> >
>> > disable_service n-net
>> >
>> > enable_service q-svc
>> >
>> > enable_service q-svc1
>> >
>> > enable_service q-dhcp
>> >
>> > enable_service q-agt
>> >
>> >
>> >
>> > And also check the configuration in Nova to use Neutron
>> >
>> >
>> >
>> > Best Regards
>> >
>> > Chaoyi Huang ( Joe Huang )
>> >
>> >
>> >
>> > From: Vega Cai [mailto:luckyveg...@gmail.com]
>> > Sent: Monday, March 28, 2016 2:55 PM
>> > To: Yipei Niu
>> > Cc: OpenStack Development Mailing List (not for usage questions);
>> joehuang
>> > Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node
>> > configuration
>> >
>> >
>> >
>> > Hi Yipei,
>> >
>> >
>> >
>> > Check "network_api_class" and "use_neutron" options in your nova.conf.
>> It
>> > seems that your nova API is not configured to use neutron.
>> >
>> >
>> >
>> > BR
>> >
>> > Zhiyuan
>> >
>> >
>> >
>> > On 28 March 2016 at 13:25, Yipei Niu  wrote:
>> >
>> > Hi, all,
>> >
>> >
>> >
>> > After I execute the command "nova boot --flavor 1 --image
>> > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
>> > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1
>> vm1",
>> > there exist some problem with the argument port. In t-ngw.log, I find
>> that
>> > the status of port switches from ACTIVE to DOWN, which is marked as bold
>> > below. Is it the reason why I failed to boot a VM?
>> >
>> >
>> >
>> > 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
>> > http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
>> > python-neutronclient" -H "X-Auth-Token:
>> 7cfcfb91173a4920adaf24db7eebd773" -d
>> > '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
>> > "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
>> >
>> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
>> >
>> > 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>> > admin^[[00;32m] ^[[01;35m^[[00

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Vega Cai]

Hi Yipei,

Check "network_api_class" and "use_neutron" options in your nova.conf. It
seems that your nova API is not configured to use neutron.

BR
Zhiyuan

On 28 March 2016 at 13:25, Yipei Niu  wrote:

> Hi, all,
>
> After I execute the command "nova boot --flavor 1 --image
> c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
> net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1 vm1",
> there exist some problem with the argument port. In t-ngw.log, I find that
> the status of port switches from ACTIVE to DOWN, which is marked as bold
> below. Is it the reason why I failed to boot a VM?
>
> 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
> python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773"
> -d '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
> "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
> 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> 'application/json; charset=UTF-8', 'Content-Length': '384',
> 'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
> {"port": {*"status": "ACTIVE"*, "name": "", "admin_state_up": true,
> "network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
> "29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
> "fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id":
> "2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}], "id":
> "e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m
> ^[[00;33mfrom (pid=17537) http_log_resp
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
> 2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> http://192.168.56.101:20001//v2.0/ports.json -X POST -H "User-Agent:
> python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773"
> -d '{"port": {"name": "e27dc15d-188f-4d60-a38c-f48052d6330b",
> "admin_state_up": true, "network_id":
> "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "tenant_id":
> "29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09",
> "fixed_ips": [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480",
> "ip_address": "10.0.8.5"}]}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
> 2016-03-28 11:49:44.669 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> 'application/json; charset=UTF-8', 'Content-Length': '808',
> 'X-Openstack-Request-Id': 'req-d286f85c-bc4b-4d7c-9915-666fe13b48b5'}
> {"port": {*"status": "DOWN"*, "binding:host_id": "",
> "allowed_address_pairs": [], "dns_assignment": [{"hostname":
> "host-10-0-8-5", "ip_address": "10.0.8.5", "fqdn":
> "host-10-0-8-5.openstacklocal."}], "device_owner": "", "binding:profile":
> {}, "port_security_enabled": true, "fixed_ips": [{"subnet_id":
> "fd1abd0d-9398-4848-a3cf-57858868a480", "ip_address": "10.0.8.5"}], "id":
> "0bbf77a4-c4e4-43ad-89a0-e55f053ef4da", "security_groups":
> ["16f02958-2a4f-4f58-b560-b9fa76be1b0c"], "device_id": "", "name":
> "e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up": true,
> "network_id": "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "dns_name": "",
> "binding:vif_details": {}, "binding:vnic_type": "normal",
> "binding:vif_type": "unbound", "tenant_id":
> "29a524d386754a94850277afea1e569f", "mac_address":
> "fa:16:3e:11:bd:09"}}^[[00m ^[[00;33mfrom (pid=17537) http_log_resp
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
> 2016-03-28 11:49:44.810 ^[[00;36mINFO eventlet.wsgi.server
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;36m] ^[[01;35m^[[00;36mTraceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line
> 454, in handle_one_response
> result = self.application(self.environ, start_response)
>   File
> "/usr/local/lib/python2.7/dist-packages/pecan/middleware/recursive.py",
> line 56, in __call__
> return self.application(environ, start_response)
>   File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
> __call__
> resp = self.call_func(req, *args, **self.kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
> call_func
> retur

Re: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name

[Vega Cai]

Added a work item in phase 4 in our todo list:

https://etherpad.openstack.org/p/TricircleToDo

On 26 March 2016 at 17:31, joehuang  wrote:

> Hi, Shinobu,
>
> This BP is a good entrance for Tricircle source code, this BP listed the
> all basic patches building Tricircle from scratches.
>
> https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, March 26, 2016 2:39 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved
> as field name
>
> Hi Team,
>
> In the Tricircle database, there are three tables having a field name
> which the MySQL (MariaDB) has as one of the reserved keywords. [1]
>
>  Table Name:
>   aggregate_metadata
>   instance_type_extra_specs
>   quality_of_service_specs
>
>  Field Name:
>   key
>
> I think it would not be best practice to use any reserved word by the any
> system because it could cause bug once the component is bigger.
>
> What do you think?
>
> [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] Using in-memory database for unit tests

[Vega Cai]

On 22 March 2016 at 12:09, Shinobu Kinjo  wrote:

> Thank you for your comment (inline for my message).
>
> On Tue, Mar 22, 2016 at 11:53 AM, Vega Cai  wrote:
> > Let me try to explain some.
> >
> > On 22 March 2016 at 10:09, Shinobu Kinjo  wrote:
> >>
> >> On Tue, Mar 22, 2016 at 10:22 AM, joehuang  wrote:
> >> > Hello, Shinobu,
> >> >
> >> > Yes, as what you described here, the "initialize" in "core.py" is used
> >> > for unit/function test only. For system integration test( for example,
> >> > tempest ), it would be better to use mysql like DB, this is done by
> the
> >> > configuration in DB part.
> >>
> >> Thank you for your thought.
> >>
> >> >
> >> > From my point of view, the tricircle DB part could be enhanced in the
> DB
> >> > model and migration scripts. Currently unit test use DB model to
> initialize
> >> > the data base, but not using the migration scripts,
> >>
> >> I'm assuming the migration scripts are in "tricircle/db". Is it right?
> >
> >
> > migration scripts are in tricircle/db/migrate_repo
> >>
> >>
> >> What is the DB model?
> >> Why do we need 2-way-methods at the moment?
> >
> >
> > DB models are defined in tricircle/db/models.py. Models.py defines
> tables in
> > object level, so other modules can import models.py then operate the
> tables
> > by operating the objects. Migration scripts defines tables in table
> level,
> > you define table fields, constraints in the scripts then migration tool
> will
> > read the scripts and build the tables.
>
> Dose "models.py" manage database schema(e.g., create / delete columns,
> tables, etc)?
>

In "models.py" we only define database schema. SQLAlchemy provides
functionality to create tables based on schema definition, which is
"ModelBase.metadata.create_all". This is used to initialized the in-memory
database for tests currently.

>
> > Migration tool has a feature to
> > generate migration scripts from DB models automatically but it may make
> > mistakes sometimes, so currently we manually maintain the table
> structure in
> > both DB model and migration scripts.
>
> Is *migration tool* different from bot DB models and migration scripts?
>

Migration tool is Alembic, a lightweight database migration tool for usage
of SQLAlchemy:

https://alembic.readthedocs.org/en/latest/

It runs migration scripts to update database schema. Each database version
has one migrate script. After defining "upgrade" and "downgrade" method in
the script, you can update your database from one version to another
version. Alembic isn't aware of DB models defined in "models.py", users
need to guarantee the version of database and the version of "models.py"
match.

If you create a new database, both "ModelBase.metadata.create_all" and
Alembic can be used. But Alembic can also be used to update an existing
database to a specific version of schema.

>
> >>
> >>
> >> > so the migration scripts can only be tested when using devstack for
> >> > integration test. It would better to using migration script to
> instantiate
> >> > the DB, and tested in the unit test too.
> >>
> >> If I understand you correctly, we are moving forward to using the
> >> migration scripts for both unit and integration tests.
> >>
> >> Cheers,
> >> Shinobu
> >>
> >> >
> >> > (Also move the discussion to the openstack-dev mail-list)
> >> >
> >> > Best Regards
> >> > Chaoyi Huang ( joehuang )
> >> >
> >> > -Original Message-
> >> > From: Shinobu Kinjo [mailto:ski...@redhat.com]
> >> > Sent: Tuesday, March 22, 2016 7:43 AM
> >> > To: joehuang; khayam.gondal; zhangbinsjtu; shipengfei92; newypei;
> >> > Liuhaixia; caizhiyuan (A); huangzhipeng
> >> > Subject: Using in-memory database for unit tests
> >> >
> >> > Hello,
> >> >
> >> > In "initialize" method defined in "core.py", we're using *in-memory*
> >> > strategy making use of sqlite. AFAIK we are using this solution for
> only
> >> > testing purpose. Unit tests using this solution should be fine for
> small
> >> > scale environment. But it's not good enough even it's for testing.
> >> >
> >> > What do you think?
> >> &

Re: [openstack-dev] [tricircle] Using in-memory database for unit tests

[Vega Cai]

Let me try to explain some.

On 22 March 2016 at 10:09, Shinobu Kinjo  wrote:

> On Tue, Mar 22, 2016 at 10:22 AM, joehuang  wrote:
> > Hello, Shinobu,
> >
> > Yes, as what you described here, the "initialize" in "core.py" is used
> for unit/function test only. For system integration test( for example,
> tempest ), it would be better to use mysql like DB, this is done by the
> configuration in DB part.
>
> Thank you for your thought.
>
> >
> > From my point of view, the tricircle DB part could be enhanced in the DB
> model and migration scripts. Currently unit test use DB model to initialize
> the data base, but not using the migration scripts,
>
> I'm assuming the migration scripts are in "tricircle/db". Is it right?
>

migration scripts are in tricircle/db/migrate_repo

>
> What is the DB model?
> Why do we need 2-way-methods at the moment?
>

DB models are defined in tricircle/db/models.py. Models.py defines tables
in object level, so other modules can import models.py then operate the
tables by operating the objects. Migration scripts defines tables in table
level, you define table fields, constraints in the scripts then migration
tool will read the scripts and build the tables. Migration tool has a
feature to generate migration scripts from DB models automatically but it
may make mistakes sometimes, so currently we manually maintain the table
structure in both DB model and migration scripts.

>
> > so the migration scripts can only be tested when using devstack for
> integration test. It would better to using migration script to instantiate
> the DB, and tested in the unit test too.
>
> If I understand you correctly, we are moving forward to using the
> migration scripts for both unit and integration tests.
>
> Cheers,
> Shinobu
>
> >
> > (Also move the discussion to the openstack-dev mail-list)
> >
> > Best Regards
> > Chaoyi Huang ( joehuang )
> >
> > -Original Message-
> > From: Shinobu Kinjo [mailto:ski...@redhat.com]
> > Sent: Tuesday, March 22, 2016 7:43 AM
> > To: joehuang; khayam.gondal; zhangbinsjtu; shipengfei92; newypei;
> Liuhaixia; caizhiyuan (A); huangzhipeng
> > Subject: Using in-memory database for unit tests
> >
> > Hello,
> >
> > In "initialize" method defined in "core.py", we're using *in-memory*
> strategy making use of sqlite. AFAIK we are using this solution for only
> testing purpose. Unit tests using this solution should be fine for small
> scale environment. But it's not good enough even it's for testing.
> >
> > What do you think?
> > Any thought, suggestion would be appreciated.
> >
> > [1]
> https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py#L124-L127
> >
> > Cheers,
> > Shinobu
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]weekly meeting of Mar. 2

[Vega Cai]

What I would like to discuss has been included :), the Reliable async, job.

BR
Zhiyuan

On 1 March 2016 at 17:19, joehuang  wrote:

> Hi,
>
>
>
> If you have any topic to discuss, please reply in the M-L.
>
>
>
> IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting
> on every Wednesday starting from UTC 13:00.
>
>
>
> Agenda:
>
> # Progress of To-do list review:
> https://etherpad.openstack.org/p/TricircleToDo
>
> # Reliable async. job
>
> # L2 networking across pods
>
> # quota management
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vega Cai]

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  wrote:

> Hi, All,
>
> Let's move the discussion to #openstack-tricircle in IRC.
>
> BR
> Zhiyuan
>
> On 1 March 2016 at 11:07, Yipei Niu  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  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:newy...@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  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:
>>&g

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

[Vega Cai]

Hi, All,

Let's move the discussion to #openstack-tricircle in IRC.

BR
Zhiyuan

On 1 March 2016 at 11:07, Yipei Niu  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  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:newy...@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  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@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
>&g

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

[Vega Cai]

Oh, I think out another reason for the problem. If you are using Vmware
Vcenter, you need to enable "Promiscuous Mode" and set "MAC Address Changes"
to "Accept".

Here is a reference in Chinese:
http://www.net130.com/CMS/Pub/special/special_virtual/special_virtual_js/2012_06_26_28741.htm

BR
Zhiyuan

On 29 February 2016 at 16:12, Vega Cai  wrote:

> Hi Pengfei,
>
> It's expected that there's no port for 100.0.0.1 since what we attach to
> router are 100.0.0.2 and 100.0.0.3.
>
> Try to ping 10.0.2.1 in vm1 and to ping 10.0.1.1 in vm2 to see if you can
> get reply. There may be security group rules that prevent vm to be accessed.
>
> The check if all the process is done, please run the following command:
>
> # get router bottom id
> neutron --os-region-name Pod1 router-list
> neutron --os-region-name Pod2 router-list
>
> # check if each router is correctly processed
> neutron --os-region-name Pod1 router-port-list 
> neutron --os-region-name Pod2 router-port-list 
> neutron --os-region-name Pod1 router-show 
> neutron --os-region-name Pod2 router-show 
>
> BR
> Zhiyuan
>
>
> On 29 February 2016 at 14:41, 时鹏飞  wrote:
>
>> And, I find ew_bridge has a gateway:
>>
>> root@node1:/home/stack# neutron subnet-show
>> 34405fae-e796-48ae-a6e7-f7943b84a117
>> +---+---+
>> | Field | Value |
>> +---+---+
>> | allocation_pools  | {"start": "100.0.0.2", "end": "100.0.0.254"}  |
>> | cidr  | 100.0.0.0/24  |
>> | dns_nameservers   |   |
>> | enable_dhcp   | False |
>> | gateway_ip| 100.0.0.1 |
>> | host_routes   |   |
>> | id| 34405fae-e796-48ae-a6e7-f7943b84a117  |
>> | ip_version| 4 |
>> | ipv6_address_mode |   |
>> | ipv6_ra_mode  |   |
>> | name  | ew_bridge_subnet_f55068b6dcfd4b4d9d357b46eedc6644 |
>> | network_id| 0828b209-71a0-481e-9e2c-5c68d2b18387  |
>> | subnetpool_id | f7360e3b-f74c-474f-9ee5-e43657dd077f  |
>> | tenant_id | f55068b6dcfd4b4d9d357b46eedc6644  |
>> +---+---+
>>
>> but in the port there is no device for gateway 100.0.0.1
>>
>> root@node1:/home/stack# neutron port-list
>>
>> +--+--+---+--+
>> | id   | name
>> | mac_address   | fixed_ips
>> |
>>
>> +--+--+---+--+
>> | 5ff4f7c4-5e47-4cc5-8a17-e011938bd930 |
>> 5ff4f7c4-5e47-4cc5-8a17-e011938bd930 | fa:16:3e:d0:1e:8e | {"subnet_id":
>> "aeb34101-0e0f-402c-94a4-e4d45235d531",|
>> |  |
>> |   | "ip_address": "10.0.2.3"}
>> |
>> | 4f2fb455-8cc5-43ea-87cd-4d4d845548a0 |
>> 4f2fb455-8cc5-43ea-87cd-4d4d845548a0 | fa:16:3e:ed:d2:49 | {"subnet_id":
>> "aeb34101-0e0f-402c-94a4-e4d45235d531",|
>> |  |
>> |   | "ip_address": "10.0.2.1"}
>> |
>> | 67e16de6-ad02-4e5f-b035-6525a5a6dcc4 |
>> | fa:16:3e:c6:07:65 | {"subnet_id":
>> "aeb34101-0e0f-402c-94a4-e4d45235d531",|
>> |  |
>> |   | "ip_address": "10.0.2.2"}
>> |
>> | 15cc5862-443f-44a0-a060-33a66b0686cc |
>> 15cc5862-443f-44a0-a060-33a66b0686cc | fa:16:3e:b9:2c:14 | {"subnet_id":
>> "34405fae-e796-48ae-a6e7-f7943b84a117",|
>> |  |
>> |   | "ip_address": "100.0.0.3"}
>> |
>> | 5367f76e-6a00-478d-b9b8-54d0b4754da7 

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

[Vega Cai]

Hi Pengfei,

It's expected that there's no port for 100.0.0.1 since what we attach to
router are 100.0.0.2 and 100.0.0.3.

Try to ping 10.0.2.1 in vm1 and to ping 10.0.1.1 in vm2 to see if you can
get reply. There may be security group rules that prevent vm to be accessed.

The check if all the process is done, please run the following command:

# get router bottom id
neutron --os-region-name Pod1 router-list
neutron --os-region-name Pod2 router-list

# check if each router is correctly processed
neutron --os-region-name Pod1 router-port-list 
neutron --os-region-name Pod2 router-port-list 
neutron --os-region-name Pod1 router-show 
neutron --os-region-name Pod2 router-show 

BR
Zhiyuan


On 29 February 2016 at 14:41, 时鹏飞  wrote:

> And, I find ew_bridge has a gateway:
>
> root@node1:/home/stack# neutron subnet-show
> 34405fae-e796-48ae-a6e7-f7943b84a117
> +---+---+
> | Field | Value |
> +---+---+
> | allocation_pools  | {"start": "100.0.0.2", "end": "100.0.0.254"}  |
> | cidr  | 100.0.0.0/24  |
> | dns_nameservers   |   |
> | enable_dhcp   | False |
> | gateway_ip| 100.0.0.1 |
> | host_routes   |   |
> | id| 34405fae-e796-48ae-a6e7-f7943b84a117  |
> | ip_version| 4 |
> | ipv6_address_mode |   |
> | ipv6_ra_mode  |   |
> | name  | ew_bridge_subnet_f55068b6dcfd4b4d9d357b46eedc6644 |
> | network_id| 0828b209-71a0-481e-9e2c-5c68d2b18387  |
> | subnetpool_id | f7360e3b-f74c-474f-9ee5-e43657dd077f  |
> | tenant_id | f55068b6dcfd4b4d9d357b46eedc6644  |
> +---+---+
>
> but in the port there is no device for gateway 100.0.0.1
>
> root@node1:/home/stack# neutron port-list
>
> +--+--+---+--+
> | id   | name
> | mac_address   | fixed_ips
> |
>
> +--+--+---+--+
> | 5ff4f7c4-5e47-4cc5-8a17-e011938bd930 |
> 5ff4f7c4-5e47-4cc5-8a17-e011938bd930 | fa:16:3e:d0:1e:8e | {"subnet_id":
> "aeb34101-0e0f-402c-94a4-e4d45235d531",|
> |  |
> |   | "ip_address": "10.0.2.3"}
> |
> | 4f2fb455-8cc5-43ea-87cd-4d4d845548a0 |
> 4f2fb455-8cc5-43ea-87cd-4d4d845548a0 | fa:16:3e:ed:d2:49 | {"subnet_id":
> "aeb34101-0e0f-402c-94a4-e4d45235d531",|
> |  |
> |   | "ip_address": "10.0.2.1"}
> |
> | 67e16de6-ad02-4e5f-b035-6525a5a6dcc4 |
> | fa:16:3e:c6:07:65 | {"subnet_id":
> "aeb34101-0e0f-402c-94a4-e4d45235d531",|
> |  |
> |   | "ip_address": "10.0.2.2"}
> |
> | 15cc5862-443f-44a0-a060-33a66b0686cc |
> 15cc5862-443f-44a0-a060-33a66b0686cc | fa:16:3e:b9:2c:14 | {"subnet_id":
> "34405fae-e796-48ae-a6e7-f7943b84a117",|
> |  |
> |   | "ip_address": "100.0.0.3"}
> |
> | 5367f76e-6a00-478d-b9b8-54d0b4754da7 |
> 5367f76e-6a00-478d-b9b8-54d0b4754da7 | fa:16:3e:01:70:36 | {"subnet_id":
> "34405fae-e796-48ae-a6e7-f7943b84a117",|
> |  |
> |   | "ip_address": "100.0.0.2"}
> |
> | 1be92584-a800-474f-a105-877e8a30875f |
> 1be92584-a800-474f-a105-877e8a30875f | fa:16:3e:5d:0d:59 | {"subnet_id":
> "6a1cafcd-6bc7-4788-8a38-b26616dd43a4",|
> |  |
> |   | "ip_address": "10.0.1.3"}
> |
> | fda27c48-ce7c-4852-b9f6-4af7da2d0b3d |
> fda27c48-ce7c-4852-b9f6-4af7da2d0b3d | fa:16:3e:26:f3:40 | {"subnet_id":
> "6a1cafcd-6bc7-4788-8a38-b26616dd43a4",|
> |  |
> |   | "ip_address": "10.0.1.1"}
> |
> | 7b51933e-edb4-4210-9df4-e346fe99fded |
> | fa:16:3e:8f:d7:ad | {"subnet_id":
> "6a1cafcd-6bc7-4788-8a38-b26616dd43a4",|
> |  |
> |   | "ip_address": "10.0.1.2"}
> |
> | 4b5a8392-abfc-4261-b98f-e39e377991a7 |
> | fa:16:3e:ae:bc:4d | " |
> |   

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

[Vega Cai]

Hi Yipei,

One reason for that error is that the API service is down. You can run
"rejoin-stack.sh" under your DevStack folder to enter the "screen" console
of DevStack, to check if services are running well. If you are not familiar
with "screen", which is a window manager for Linux, you can do a brief
search.

One more thing you can try, change the IP address to 127.0.0.1 and issue
the request in the machine hosting the services to see if there is still
"Connection refused" error.

BR
Zhiyuan

On 20 February 2016 at 20:49, Yipei Niu  wrote:

> Hi Joe and Zhiyuan,
>
> I encounter an error when executing the following command:
>
> stack@nyp-VirtualBox:~/devstack$ curl -X POST
> http://192.168.56.101:1/v1.0/pods -H "Content-Type: application/json"
> -H "X-Auth-Token: 0ead350329ef4b07ab3b823a9d37b724" -d '{"pod":
> {"pod_name":  "RegionOne"}}'
> curl: (7) Failed to connect to 192.168.56.101 port 1: Connection
> refused
>
> Before executing the command, I source the file "userrc_early", whose
> content is as follows:
> export OS_IDENTITY_API_VERSION=3
> export OS_AUTH_URL=http://192.168.56.101:35357
> export OS_USERNAME=admin
> export OS_USER_DOMAIN_ID=default
> export OS_PASSWORD=nypnyp0316
> export OS_PROJECT_NAME=admin
> export OS_PROJECT_DOMAIN_ID=default
> export OS_REGION_NAME=RegionOne
>
> Furthermore, the results of "openstack endpoint list" are as follows:
> stack@nyp-VirtualBox:~/devstack$ openstack endpoint list
>
> +--+---+--++-+---++
> | ID   | Region| Service Name | Service
> Type   | Enabled | Interface | URL
>|
>
> +--+---+--++-+---++
> | 0702ff208f914910bf5c0e1b69ee73cc | RegionOne | nova_legacy  |
> compute_legacy | True| internal  |
> http://192.168.56.101:8774/v2/$(tenant_id)s|
> | 07fe31211a234566a257e3388bba0393 | RegionOne | nova_legacy  |
> compute_legacy | True| admin |
> http://192.168.56.101:8774/v2/$(tenant_id)s|
> | 11cea2de9407459480a30b190e005a5c | Pod1  | neutron  | network
>  | True| internal  | http://192.168.56.101:20001/
>   |
> | 16c0d9f251d84af897dfdd8df60f76dd | Pod2  | nova_legacy  |
> compute_legacy | True| admin |
> http://192.168.56.102:8774/v2/$(tenant_id)s|
> | 184870e1e5df48629e8e1c7a13c050f8 | RegionOne | cinderv2 | volumev2
> | True| public| http://192.168.56.101:19997/v2/$(tenant_id)s
>   |
> | 1a068f85aa12413582c4f4d256d276af | Pod2  | nova | compute
>  | True| admin | http://192.168.56.102:8774/v2.1/$(tenant_id)s
>  |
> | 1b3799428309490bbce57043e87ac815 | RegionOne | cinder   | volume
> | True| internal  | http://192.168.56.101:8776/v1/$(tenant_id)s
>  |
> | 221d74877fdd4c03b9b9b7d752e30473 | Pod2  | neutron  | network
>  | True| internal  | http://192.168.56.102:9696/
>|
> | 413de19152f04fc6b2b1f3a1e43fd8eb | Pod2  | cinderv2 | volumev2
> | True| public| http://192.168.56.102:8776/v2/$(tenant_id)s
>  |
> | 42e1260ab0854f3f807dcd67b19cf671 | RegionOne | keystone | identity
> | True| admin | http://192.168.56.101:35357/v2.0
>   |
> | 45e4ccd5e16a423e8cb9f59742acee27 | Pod1  | neutron  | network
>  | True| public| http://192.168.56.101:20001/
>   |
> | 464dd469545b4eb49e53aa8dafc114bc | RegionOne | cinder   | volume
> | True| admin | http://192.168.56.101:8776/v1/$(tenant_id)s
>  |
> | 47351cda93a54a2a9379b83c0eb445ca | Pod2  | neutron  | network
>  | True| admin | http://192.168.56.102:9696/
>|
> | 56d6f7641ee84ee58611621c4657e45d | Pod2  | nova_legacy  |
> compute_legacy | True| internal  |
> http://192.168.56.102:8774/v2/$(tenant_id)s|
> | 57887a9d15164d6cb5b58d9342316cf7 | RegionOne | glance   | image
>  | True| internal  | http://192.168.56.101:9292
>   |
> | 5f2a4f69682941edbe54a85c45a5fe1b | Pod1  | cinderv2 | volumev2
> | True| public| http://192.168.56.101:8776/v2/$(tenant_id)s
>  |
> | 6720806fe7e24a7c8335159013dba948 | Pod2  | cinderv2 | volumev2
> | True| admin | http://192.168.56.102:8776/v2/$(tenant_id)s
>  |
> | 72e2726b55414d25928b4fc9925a06ed | RegionOne | nova_legacy  |
> compute_legacy | True| public|
> http://192.168.56.101:8774/v2/$(tenant_id)s|
> | 75163e97c3014a389ab56184f970908f | Pod2  | neutron  | network
>  | True| public| http://192.168.56.102:9696/
>|
> | 77b67589282e4776916ead802646de11 | Pod1  | nova | compute
>  | True| internal  | http://192.168.56.101:8774/v2.1/$(tenant_id)s
>  |
> | 789f3456899f4381aef850822c412436 | Pod2  | nova | compute
>  | True| internal  | http://19

[openstack-dev] [tricircle] DHCP port problem

[Vega Cai]

Hi all,

When implementing L3 north-south networking functionality, I meet the DHCP
port problem again.

First let me briefly explain the DHCP port problem. In Tricircle, we have a
Neutron server using Tricircle plugin in top pod to take control all the
Neutron servers in bottom pods. The strategy of Tricircle to avoid IP
address conflict is that IP address allocation is done on top and we create
port with IP address specified in bottom pod. However, the behavior of
Neutron to create DHCP port has been changed. Neutron no longer waits for
the creation of the first VM to schedule DHCP agent, but schedule DHCP
agent when subnet is created, then the bound DHCP agent will automatically
create DHCP port. So we have no chance to specify the IP address of DHCP
port. Since the IP address of DHCP port is not reserved in top pod, we have
risk to encounter IP address conflict.

How we solve this problem for VM creation is that we still create a DHCP
port first, then use the IP address of the port to create DHCP port in
bottom pod. If we get an IP address conflict exception, we check if the
bottom port is a DHCP port, if so, we directly use this bottom port and
build a id mapping. If we successfully create the bottom DHCP port, we
check if there are other DHCP ports in bottom pod in the same subnet and
remove them.

Now let's go back to the L3 north-south networking functionality
implementation. If user creates a port and then associates it with a
floating IP before booting a VM, Tricircle plugin needs to create the
bottom internal port first in order to setup bottom floating IP. So again
we have risk that the IP address of the internal port conflicts with the IP
address of a bottom DHCP port.

Below I list some choices to solve this problem:
(1) Always create internal port in Nova gateway so we can directly use the
codes handling DHCP problem in Nova gateway. This will also leave floating
IP stuff to Nova gateway.

(2) Transplant the codes handling DHCP problem from Nova gateway to
Tricircle plugin. Considering there are already a lot of things to do when
associating floating IP, this will make floating IP association more
complex.

(3) Anytime we need to create a bottom subnet, we disable DHCP in this
subnet first so bottom DHCP port will not be created automatically. When we
are going to boot a VM, we create DHCP port in top and bottom pod then
enable DHCP in bottom subnet. When a DHCP agent is scheduled, it will check
if there exists a port whose device_id is "reserved_dhcp_port" and use it
as the DHCP port. By creating a bottom DHCP port with device_id set to
"reserved_dhcp_port", we can guide DHCP agent to use the port we create.

I think this problem can be solved in a separate patch and I will add a
TODO in the patch for L3 north-south networking functionality.

Any comments or suggestions?

BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Port Query Performance Test

[Vega Cai]

Hi all,

I did a test about the performance of port query in Tricircle yesterday.
The result is attached.

Three observations in the test result:
(1) Neutron client costs much more time than curl, the reason may be
neutron client needs to apply for a new token in each run.
(2) Eventlet doesn't bring much improvement, the reason may be we only have
two bottom pods. I will add some logs to do a further investigation.
(3) Query 1000 ports in top pod costs about 1.5s when using curl, which is
acceptable.

BR
Zhiyuan


tricircle-query-test.xlsx
Description: MS-Excel 2007 spreadsheet
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle]Question regarding pep8 test

[Vega Cai]

Hi Khayam,

Could you check the version of your flake8? It's located in .tox/pep8/bin.

D102 is one of the pep8 error, and I find it's not ignored in Tricircle
tox.ini, so I guess that flake8 on Jenkins doesn't enable this error by
default but in your flake8, this error is enabled.

I check the log of one successful Jenkins job on Tricircle and list the
version of flake8 and related packages Jenkins uses below:

flake8==2.2.4
hacking==0.10.2
pyflakes==0.8.1
mccabe==0.2.1

BR
Zhiyuan

On 3 February 2016 at 14:53, Zhipeng Huang  wrote:

> Hi Khayam,
>
> We try to get every communication on the mailing list for transparency :)
> So I copied your email here.
>
> -
>
> Zhiyan pls check to see what happened.
>
> Sent from HUAWEI AnyOffice
>
>
> -
>
> Hi Chaoyi,
>
> When I run local *pep8 *test using* tox -e pep8*, It always shows error
> regarding
>
> *./tricircle/tests/unit/network/test_plugin.py:268:1: D102  Missing
> docstring in public method*
>
> but on Jenkins no such errors are shown. Due to this contradictory
> behavior, I am unable to locally test *pep8*.
>
> May be there is something I am missing or not well using. Is it possible
> for you to guide me through.
>
>
>
> Regards
>
> Khayam
>
> 
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] Playing Tricircle with Devstack

[Vega Cai]

Hi Yipei,

I checked the Git commit history of DevStack and found a recent commit
changed the order of sourcing userrc_early and creating keystone account.
Before the commit, DevStack created keystone account before sourced
userrc_early so there was not problem. After the commit, now,
DevStack sources userrc_early before creates keystone account,
OS_REGION_NAME is changed to REGION_NAME(Pod2), keystone tries to find
tenant admin in Pod2, and thus fails.

However, we do need to set REGION_NAME as Pod2 in node2, because we would
to setup another region in node2.

Maybe you can change stack.sh a bit, change line 1025 from
export OS_REGION_NAME=$REGION_NAME
to
export OS_REGION_NAME=RegionOne
so keystone can use the correct region.

OR

remove line 1031
create_keystone_accounts
Since we don't need to setup keystone account in node2.

If my analysis is correct, this is a bug of DevStack which stops supporting
multiple region deployment.

On 26 January 2016 at 14:28, joehuang  wrote:

> Except paste the result for the command with –debug parameter  "openstack
> --debug project show admin -f value -c id" in Node2, please also attach
> your configuration file in Node1 and Node2 ( local.conf in the devstack
> folder )
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
> *From:* Vega Cai [mailto:luckyveg...@gmail.com]
> *Sent:* Tuesday, January 26, 2016 10:03 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [tricircle] Playing Tricircle with Devstack
>
>
>
> Strange... One suggestion to dig into this problem is that you add a
> "--debug" parameter to the command like:
>
>
>
> "openstack --debug project show admin -f value -c id"
>
>
>
> and run DevStack again. With "--debug" parameter, OpenStack client will
> print out raw HTTP request and response so may bring you more information
> to find out the cause of the problem.
>
>
>
> On 25 January 2016 at 22:21, Zhipeng Huang  wrote:
>
> cc'ed Joe.
>
>
>
> Yipei I think you could refer to this bug:
> https://bugs.launchpad.net/devstack/+bug/1490950
>
>
>
> On Mon, Jan 25, 2016 at 4:13 PM, Yipei Niu  wrote:
>
> There doesn't any problems when installing devstack on node1. However,
> when install devstack to node2, I encounter an error and the trace is as
> follows:
>
>
>
> 2016-01-25 07:40:47.068 | + echo -e Starting Keystone
>
> 2016-01-25 07:40:47.069 | + '[' 192.168.56.101 == 192.168.56.102 ']'
>
> 2016-01-25 07:40:47.070 | + is_service_enabled tls-proxy
>
> 2016-01-25 07:40:47.091 | + return 1
>
> 2016-01-25 07:40:47.091 | + cat
>
> 2016-01-25 07:40:47.093 | + source /home/stack/devstack/userrc_early
>
> 2016-01-25 07:40:47.095 | ++ export OS_IDENTITY_API_VERSION=3
>
> 2016-01-25 07:40:47.095 | ++ OS_IDENTITY_API_VERSION=3
>
> 2016-01-25 07:40:47.095 | ++ export OS_AUTH_URL=
> http://192.168.56.101:35357
>
> 2016-01-25 07:40:47.095 | ++ OS_AUTH_URL=http://192.168.56.101:35357
>
> 2016-01-25 07:40:47.095 | ++ export OS_USERNAME=admin
>
> 2016-01-25 07:40:47.095 | ++ OS_USERNAME=admin
>
> 2016-01-25 07:40:47.095 | ++ export OS_USER_DOMAIN_ID=default
>
> 2016-01-25 07:40:47.095 | ++ OS_USER_DOMAIN_ID=default
>
> 2016-01-25 07:40:47.096 | ++ export OS_PASSWORD=nypnyp0316
>
> 2016-01-25 07:40:47.096 | ++ OS_PASSWORD=nypnyp0316
>
> 2016-01-25 07:40:47.096 | ++ export OS_PROJECT_NAME=admin
>
> 2016-01-25 07:40:47.097 | ++ OS_PROJECT_NAME=admin
>
> 2016-01-25 07:40:47.098 | ++ export OS_PROJECT_DOMAIN_ID=default
>
> 2016-01-25 07:40:47.099 | ++ OS_PROJECT_DOMAIN_ID=default
>
> 2016-01-25 07:40:47.100 | ++ export OS_REGION_NAME=Pod2
>
> 2016-01-25 07:40:47.101 | ++ OS_REGION_NAME=Pod2
>
> 2016-01-25 07:40:47.102 | + create_keystone_accounts
>
> 2016-01-25 07:40:47.105 | + local admin_tenant
>
> 2016-01-25 07:40:47.111 | ++ openstack project show admin -f value -c id
>
> 2016-01-25 07:40:48.408 | Could not find resource admin
>
> 2016-01-25 07:40:48.452 | + admin_tenant=
>
> 2016-01-25 07:40:48.453 | + exit_trap
>
> 2016-01-25 07:40:48.454 | + local r=1
>
> 2016-01-25 07:40:48.456 | ++ jobs -p
>
> 2016-01-25 07:40:48.461 | + jobs=
>
> 2016-01-25 07:40:48.464 | + [[ -n '' ]]
>
> 2016-01-25 07:40:48.464 | + kill_spinner
>
> 2016-01-25 07:40:48.464 | + '[' '!' -z '' ']'
>
> 2016-01-25 07:40:48.464 | + [[ 1 -ne 0 ]]
>
> 2016-01-25 07:40:48.464 | + echo 'Error on exit'
>
> 2016-01-25 07:40:48.464 | Error on exit
>
> 2016-01-25 07:40:48.464 | + generate-subunit 1453707531 117 fail

Re: [openstack-dev] [tricircle] Playing Tricircle with Devstack

[Vega Cai]

Strange... One suggestion to dig into this problem is that you add a
"--debug" parameter to the command like:

"openstack --debug project show admin -f value -c id"

and run DevStack again. With "--debug" parameter, OpenStack client will
print out raw HTTP request and response so may bring you more information
to find out the cause of the problem.

On 25 January 2016 at 22:21, Zhipeng Huang  wrote:

> cc'ed Joe.
>
> Yipei I think you could refer to this bug:
> https://bugs.launchpad.net/devstack/+bug/1490950
>
> On Mon, Jan 25, 2016 at 4:13 PM, Yipei Niu  wrote:
>
>> There doesn't any problems when installing devstack on node1. However,
>> when install devstack to node2, I encounter an error and the trace is as
>> follows:
>>
>> 2016-01-25 07:40:47.068 | + echo -e Starting Keystone
>> 2016-01-25 07:40:47.069 | + '[' 192.168.56.101 == 192.168.56.102 ']'
>> 2016-01-25 07:40:47.070 | + is_service_enabled tls-proxy
>> 2016-01-25 07:40:47.091 | + return 1
>> 2016-01-25 07:40:47.091 | + cat
>> 2016-01-25 07:40:47.093 | + source /home/stack/devstack/userrc_early
>> 2016-01-25 07:40:47.095 | ++ export OS_IDENTITY_API_VERSION=3
>> 2016-01-25 07:40:47.095 | ++ OS_IDENTITY_API_VERSION=3
>> 2016-01-25 07:40:47.095 | ++ export OS_AUTH_URL=
>> http://192.168.56.101:35357
>> 2016-01-25 07:40:47.095 | ++ OS_AUTH_URL=http://192.168.56.101:35357
>> 2016-01-25 07:40:47.095 | ++ export OS_USERNAME=admin
>> 2016-01-25 07:40:47.095 | ++ OS_USERNAME=admin
>> 2016-01-25 07:40:47.095 | ++ export OS_USER_DOMAIN_ID=default
>> 2016-01-25 07:40:47.095 | ++ OS_USER_DOMAIN_ID=default
>> 2016-01-25 07:40:47.096 | ++ export OS_PASSWORD=nypnyp0316
>> 2016-01-25 07:40:47.096 | ++ OS_PASSWORD=nypnyp0316
>> 2016-01-25 07:40:47.096 | ++ export OS_PROJECT_NAME=admin
>> 2016-01-25 07:40:47.097 | ++ OS_PROJECT_NAME=admin
>> 2016-01-25 07:40:47.098 | ++ export OS_PROJECT_DOMAIN_ID=default
>> 2016-01-25 07:40:47.099 | ++ OS_PROJECT_DOMAIN_ID=default
>> 2016-01-25 07:40:47.100 | ++ export OS_REGION_NAME=Pod2
>> 2016-01-25 07:40:47.101 | ++ OS_REGION_NAME=Pod2
>> 2016-01-25 07:40:47.102 | + create_keystone_accounts
>> 2016-01-25 07:40:47.105 | + local admin_tenant
>> 2016-01-25 07:40:47.111 | ++ openstack project show admin -f value -c id
>> 2016-01-25 07:40:48.408 | Could not find resource admin
>> 2016-01-25 07:40:48.452 | + admin_tenant=
>> 2016-01-25 07:40:48.453 | + exit_trap
>> 2016-01-25 07:40:48.454 | + local r=1
>> 2016-01-25 07:40:48.456 | ++ jobs -p
>> 2016-01-25 07:40:48.461 | + jobs=
>> 2016-01-25 07:40:48.464 | + [[ -n '' ]]
>> 2016-01-25 07:40:48.464 | + kill_spinner
>> 2016-01-25 07:40:48.464 | + '[' '!' -z '' ']'
>> 2016-01-25 07:40:48.464 | + [[ 1 -ne 0 ]]
>> 2016-01-25 07:40:48.464 | + echo 'Error on exit'
>> 2016-01-25 07:40:48.464 | Error on exit
>> 2016-01-25 07:40:48.464 | + generate-subunit 1453707531 117 fail
>> 2016-01-25 07:40:48.885 | + [[ -z /opt/stack/logs ]]
>> 2016-01-25 07:40:48.886 | + /home/stack/devstack/tools/worlddump.py -d
>> /opt/stack/logs
>> 2016-01-25 07:40:48.944 | df: '/run/user/112/gvfs': Permission denied
>> 2016-01-25 07:40:49.166 | + exit 1
>>
>> Could you please give me some advice on solving it?
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] DAL progress

[Vega Cai]

Hi folks,

As we discussed before, DAL needs to provide API to access resources in the
top and bottom OpenStack, so I implemented a client wrapper which has API
like this:

list_servers(self, cxt, site, fileters)

cxt is the context object storing authorization information, site tells DAL
where to send the REST request.

We have a "siteserviceconfiguration" table, and we have three choices how
to use it.

1. We don't have an admin account, and we don't store service
catalog(returned from Keystone when getting token, containing endpoint
information) in cxt, then there's no way we can retrieve endpoints from
Keystone, so we need to query endpoints from "siteserviceconfiguration"
table. User needs to register site-service mapping via cascade service API,
and if endpoints are updated in Keystone, user needs to update the mapping.

2. We don't have an admin account but we use service catalog, then cascade
service needs to fill cxt with service catalog, so DAL can obtain endpoints
from cxt. Endpoint update has no impact since we always have the newest
endpoint information.

3. We have an admin account, then we can retrieve endpoints via
endpoint-list.
(1) Use "siteserviceconfiguration" table as cache, then DAL needs to update
this table when client fails to connect services(endpoints may be updated)
(2) No cache, then endpoint update again has no impact.

BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] local pluggable cascaded service

[Vega Cai]

Agree that we use polling mode to synchronize resource status, but it's a
bit weird to deploy a localized service for just polling. Maybe we can
define a status synchronizatioin task to handle such work so it can be done
by cascade service itself. If multiple cascade service is deployed, to
avoid conflict, we can utilize leader selection (provided by zookeeper and
other tools) to find a leader cascade service. Leader cascade service is
responsible for periodically creating status synchronization task and other
members finish the task.

BR
Zhiyuan

On 3 August 2015 at 14:48, joehuang  wrote:

> Hi,
>
>
>
> In the PoC, the status synchronization is done by the proxy node running
> with periodic task to poll the recent changed status, for example, VM
> status, volume status, and port status, etc. One proxy node will be
> responsible for one cascaded OpenStack instance, and configured with one
> user to be able to query the status. It works, although not perfect, and
> the controllable.
>
>
>
> During the last weekly meeting, Gampel mentioned that to have a local
> pluggable cascaded service for "port status" and other site-localized
> information collection, and push to the top layer cascade service. I would
> like to know more your thoughts on the “push” method.
>
>
>
> 1.  We cannot push every status change to the top layer, especially
> if one site’s down and restart all service, then all object’s status will
> be changed frequently in very short time, if “push” based on every status,
> imaging that  there are lots of objects in one site, the burst API calling
> to the top layer will be un-controllable.
>
>
>
> 2.  The local cascaded service has to listen on the message bus to
> track each status change event of all objects. It’ll work like Ceilometers
> agent to capture the status change events. Not all status change will send
> notification even to the message bus, have to add code to each service.
> It’s also complex to implement.
>
>
>
> To my understanding, the more viable way is to deploy a localized service,
> but still using polling method to get the status, and send to the up layer
> in batch mode to reduce the number of API calling to the top layer.
>
>
>
> In the top layer, using a task to process the status change in case of
> burst status refresh.
>
>
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tricircle] DAL implementation

[Vega Cai]

Hi Joe,

I think one independent job is finished in one session. The job is
responsible to start  a session, query or modify database then end the
session. Like port creating job in neutron, it starts a session, queries
network, adds port, allocates ip address, then ends the session at the end.

BR
Zhiyuan

On 31 July 2015 at 09:05, joehuang  wrote:

> Hi, Vega,
>
>
>
> Multiple DB access will be a use case for one session , especially for DB
> data insertion, multiple table will be involved. To embed the session in
> Context, it’s ok to start a session if the session is empty, but how to
> decide when to commit the data, end a session?
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
> *From:* Vega Cai [mailto:luckyveg...@gmail.com]
> *Sent:* Thursday, July 30, 2015 3:03 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [tricircle] DAL implementation
>
>
>
> Hi folks,
>
>
>
> In my current implementation, there are a core module and a models module.
> Core module handles all the database stuff, start a session, issue sql
> operation, then end a session. Models module invokes methods in core module
> to access database, as showed below:
>
>
>
> model.py
>
> def get_site(site_id):
>
> core.get_resource(Site, site_id)
>
>
>
> core.py
>
> def get_resource(model, pk_value):
>
> # code to access database
>
>
>
> To add context, I am going to implement like this:
>
>
>
> model.py
>
> def get_site(context, site_id):
>
> policy_check(context)
>
> core.get_resource(Site, site_id)
>
>
>
> core.py
>
> def get_resource(model, pk_value):
>
> # code to access database
>
>
>
> So there is no need to embed session into context.
>
>
>
> One advantage of embedding session into context is that you can combine
> more than one method calls in one session, like:
>
>
>
> model.py
>
> def complex_operation(context):
>
> policy_check(context)
>
> with context.session.begin():
>
> core.operation1(context)
>
> core.operation2(context)
>
>
>
> But this approach moves session handling from core module to models module
> and core module just provides some utility methods.
>
>
>
> I'm not sure which one is better.
>
>
>
> BR
>
> Zhiyuan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] DAL implementation

[Vega Cai]

Hi folks,

In my current implementation, there are a core module and a models module.
Core module handles all the database stuff, start a session, issue sql
operation, then end a session. Models module invokes methods in core module
to access database, as showed below:

model.py
def get_site(site_id):
core.get_resource(Site, site_id)

core.py
def get_resource(model, pk_value):
# code to access database

To add context, I am going to implement like this:

model.py
def get_site(context, site_id):
policy_check(context)
core.get_resource(Site, site_id)

core.py
def get_resource(model, pk_value):
# code to access database

So there is no need to embed session into context.

One advantage of embedding session into context is that you can combine
more than one method calls in one session, like:

model.py
def complex_operation(context):
policy_check(context)
with context.session.begin():
core.operation1(context)
core.operation2(context)

But this approach moves session handling from core module to models module
and core module just provides some utility methods.

I'm not sure which one is better.

BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev