Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-09-01 Thread joehuang
. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-09-01 Thread joehuang
, joehuang wrote: Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations

[openstack-dev] [Neutron] timestamp for Neutron object

2014-09-18 Thread joehuang
Hello, Sorry I don't know what happened in the history of Neutron DB design. It's very strange that there is no timestamp for Neutron objects, especially for Port. Nova/Cinder has timestamp field for almost all objects. Port status will be changed timely, it's very useful to record the

Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-09-24 Thread joehuang
+1. Or at least provide a way to specify an external UUID for the instance, and can retrieve the instance through the external UUID which may be linked to external system's object. Chaoyi Huang ( joehuang ) 发件人: Pasquale Porreca [pasquale.porr

Re: [openstack-dev] Performance of security group

2014-06-26 Thread joehuang
Interesting idea to optimize the performance. Not only security group rule will leads to fanout message load, we need to review and check to see if all fanout usegae in Neutron could be optimized. For example, L2 population: self.fanout_cast(context, self.make_msg(method,

Re: [openstack-dev] DVR and FWaaS integration

2014-06-29 Thread joehuang
From real solution scenario, we usually have to integrate hardware to provide tenant north-south traffic. So the DVR should work not only for distributed FWaaS, but also for central FWaaS/SNAT/FIP for north-south traffic. Best Regards Chaoyi Huang ( Joe Huang ) 发件人: Richard Woo

Re: [openstack-dev] DVR and FWaaS integration

2014-07-02 Thread joehuang
Hello, It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that

Re: [openstack-dev] REST API access to configuration options

2014-07-15 Thread joehuang
Hello, My personal view is that not to put all configuration options being accessed by RESTFUL API, but for these configurations which will leads to restart the controller nodes should be able to be configured dynamically through RESTFUL api. There are lots of configuration change only

Re: [openstack-dev] [Neutron] Auth token in context

2014-07-18 Thread joehuang
Hello, Phillip. Currently, Neutron did not pass the token to the context. But Nova/Cinder did that. It's easy to do that, just 'copy' from Nova/Cinder. 1. How Nova/Cinder did that class NovaKeystoneContext(wsgi.Middleware) ///or CinderKeystoneContext for cinder auth_token =

[openstack-dev] 答复: [Neutron] Auth token in context

2014-07-20 Thread joehuang
for the token. So to be clear, you agree that it should at least be passed to context and because its not could be deemed a bug? Thank you On 7/18/14 2:03 AM, joehuang joehu...@huawei.commailto:joehu...@huawei.com wrote: Hello, Phillip. Currently, Neutron did not pass the token to the context

Re: [openstack-dev] [all] specs.openstack.org is live

2014-08-04 Thread joehuang
Hi, Good job! I would like to know how to submit cross project spec? Is there a repository for cross project cross project spec. Best Regards Chaoyi Huang ( Joe Huang ) -邮件原件- 发件人: Andreas Jaeger [mailto:a...@suse.com] 发送时间: 2014年8月3日 1:17 收件人: openstack-dev@lists.openstack.org 主题:

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

2014-05-13 Thread joehuang
Hi All, Totally agree with Allamaraju. Only hierarchical administrative boundary is not enough, the definition of internal network architecture within one domain is very important. The networking among projects in one domain could be isolated or not, the access to external network may be not

Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-09-24 Thread joehuang
be thorough when making API changes like this. On Wed, Sep 24, 2014 at 6:56 AM, joehuang joehu...@huawei.commailto:joehu...@huawei.com wrote: +1. Or at least provide a way to specify an external UUID for the instance, and can retrieve the instance through the external UUID which may be linked

[openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
Hello, Dear TC and all, Large cloud operators prefer to deploy multiple OpenStack instances(as different zones), rather than a single monolithic OpenStack instance because of these reasons: 1) Multiple data centers distributed geographically; 2) Multi-vendor business policy; 3) Server nodes

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
with OpenStack API exposed. Cells: a single OpenStack instance scale up methodology Therefore, no conflict between Cells and OpenStack cascading. They can be used for different scenario, and Cells can also be used as the cascaded OpenStack (the child OpenStack). Best Regards Chaoyi Huang ( joehuang

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
for the integration of software / hardware . Best Regards Chaoyi Huang ( joehuang) From: John Griffith [john.griff...@solidfire.com] Sent: 01 October 2014 0:10 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
session. Best Regards Chaoyi Hunag ( joehuang ) From: Joe Gordon [joe.gord...@gmail.com] Sent: 01 October 2014 2:06 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
distributed system we have, no conflict, no matter OpenStack cascading introduced or not, we need a solid, stable and scalable OpenStack. 6. How I imagine this working out (in my view), all these things are good, I also like it. Best Regards Chaoyi Hunag ( joehuang

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
point of view. Best Regards Chaoyi Huang ( joehuang ) From: Andrew Laski [andrew.la...@rackspace.com] Sent: 01 October 2014 3:49 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread joehuang
( joehuang ) From: Adam Young [ayo...@redhat.com] Sent: 01 October 2014 4:25 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading On 09/30/2014 12:10 PM, John Griffith wrote: On Tue, Sep

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-01 Thread joehuang
Regards Chaoyi Huang ( joehuang ) From: Tom Fifield [t...@openstack.org] Sent: 01 October 2014 15:19 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi Joe, On 01/10/14 09:10

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-01 Thread joehuang
/messagebus/backend drivers/controller node configuration can be different for different cascaded OpenStack. Best regards Chaoyi Huang ( joehuang ) From: loy wolfe [loywo...@gmail.com] Sent: 01 October 2014 16:13 To: OpenStack Development Mailing List

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-01 Thread joehuang
Huang ( joehuang ) From: Alex Glikson [glik...@il.ibm.com] Sent: 01 October 2014 12:51 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This sounds related

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-01 Thread joehuang
the formal Paris design summit, so that we can exchange ideas completely. 40 minutes design summit session is not enough for deep diving. PoC team will stay at Paris from Oct.29 to Nov.8. Best Regards Chaoyi Huang ( joehuang ) From: Tiwari, Arvind [arvind.tiw

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-02 Thread joehuang
in the OpenStack cascading? Best Regards Chaoyi Huang ( joehuang ) From: Duncan Thomas [duncan.tho...@gmail.com] Sent: 02 October 2014 18:59 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-02 Thread joehuang
and date-time. Best Regards Chaoyi Huang ( joehuang ) From: Duncan Thomas [duncan.tho...@gmail.com] Sent: 02 October 2014 22:33 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-02 Thread joehuang
. Could you come to Paris a little early, I am afraid we have to prepare live demo on Nov.2, and Nov.3 is a very busy day. The f2f deep diving would be better to have before Nov.2. Please follow this thread for the venue and date-time. Best Regards. Chaoyi Huang ( joehuang

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-07 Thread joehuang
. Best Regards Chaoyi Huang ( joehuang ) From: Joshua Harlow [harlo...@outlook.com] Sent: 07 October 2014 12:21 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread joehuang
developed totally new API for Node-pool, it takes long time to grow API-ecosystem or 3rd party APP for it. Best Regards Chaoyi Huang ( joehuang ) -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Tuesday, October 07, 2014 11:44 PM To: OpenStack Development

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-08 Thread joehuang
of yet. On 7 October 2014 14:24, joehuang joehu...@huawei.com wrote: Hello, Joshua, Thank you for your concerns on OpenStack cascading. I am afraid that I am not proper person to give comment on cells, but I would like to speak a little about cascading for you mentioned with its own set

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-09 Thread joehuang
Hello, Duncan, You are right. It's not simple multiplier game. The performance or scalability bottleneck is mainly impacted from two aspect: request concurrency to the cloud, and the volume of the objects (including VM,Volume,Port,etc). We can discuss that in a scenario: there are 1 million

Re: [openstack-dev] Cells conversation starter

2014-10-21 Thread joehuang
Hi, Many thanks to Steve to link these topics together. +1 Consider that there are lots of production installation of cells solution, the improvement on cells are definitely necessary. And also hope to add the following demand for the large cloud operator ( especially cloud for NFV ) in the

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-23 Thread joehuang
/ Cinder with federated Neutron, this point can be arhieved. Best Regards Chaoyi Huang ( joehuang ) -Original Message- From: henry hly [mailto:henry4...@gmail.com] Sent: Thursday, October 23, 2014 3:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-23 Thread joehuang
From: Day, Phil [philip@hp.com] Sent: 23 October 2014 19:24 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, -Original Message- From: joehuang [mailto:joehu

Re: [openstack-dev] [All] Finalizing cross-project design summit track

2014-10-28 Thread joehuang
://kilodesignsummit.sched.org/type/cross-project+workshops [2] https://etherpad.openstack.org/p/kilo-crossproject-summit-topics Best Regards Chaoyi Huang ( joehuang ) From: Russell Bryant [rbry...@redhat.com] Sent: 29 October 2014 5:22 To: OpenStack Development

Re: [openstack-dev] [All] Finalizing cross-project design summit track

2014-10-29 Thread joehuang
Thanks for your confirmation. Best Regards Chaoyi Huang ( joehuang ) From: Thierry Carrez [thie...@openstack.org] Sent: 29 October 2014 16:55 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [All] Finalizing cross-project design summit

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-29 Thread joehuang
Chaoyi Hunag ( joehuang ) From: Wuhongning [wuhongn...@huawei.com] Sent: 30 October 2014 10:25 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-30 Thread joehuang
( joehuang ) From: A, Keshava [keshav...@hp.com] Sent: 30 October 2014 17:45 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, Can the VM migration

Re: [openstack-dev] [Neutron] L2 Gateway discussion

2014-11-07 Thread joehuang
Hi, Why not use already defined multi-segements (or multi-provider-network) API interface, and hide the L2GW explicit manipulation? Best Regards Chaoyi Huang ( joehuang ) From: Sukhdev Kapur [sukhdevka...@gmail.com] Sent: 06 November 2014 19:27

Re: [openstack-dev] Quota management and enforcement across projects

2014-11-19 Thread joehuang
+1 There are lots of concurrent requests to the quota management service if it's shared for projects, especially if it's shared for multi-regions (KeyStone can be global service for multi-regions), also latency will affect the end user experience. POC is good idea to verify the concept. Best

[openstack-dev] [Keystone] internalURL and adminURL of endpoints should not be visible to ordinary user

2014-11-28 Thread joehuang
Hello, if an ordinary user sent a get-token request to KeyStone, internalURL and adminURL of endpoints will also be returned. It'll expose the internal high privilege access address and some internal network topology information to the ordinary user, and leads to the risk for malicious user to

[openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-02 Thread joehuang
Huang (joehuang) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-05 Thread joehuang
.html Best Regards Chaoyi Huang (joehuang) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-05 Thread joehuang
want the ecosystem friendly global open API for the mutli-site cloud for global access. Best Regards Chaoyi Huang ( joehuang ) From: Davanum Srinivas [dava...@gmail.com] Sent: 05 December 2014 21:56 To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] Cross-Project meeting, Tue December 9th, 21:00 UTC

2014-12-09 Thread joehuang
Hi, If time is available, how about adding one agenda to guide the direction for cascading to move forward? Thanks in advance. The topic is : Need cross-program decision to run cascading as an incubated project mode or register BP separately in each involved project. CI for cascading is

Re: [openstack-dev] Cross-Project meeting, Tue December 9th, 21:00 UTC

2014-12-09 Thread joehuang
Hello, Thierry, That sounds great. Best Regards Chaoyi Huang ( joehuang ) From: Thierry Carrez [thie...@openstack.org] Sent: 09 December 2014 18:32 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Cross-Project meeting, Tue December

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-11 Thread joehuang
recap and move forward On Fri, Dec 5, 2014 at 8:23 AM, joehuang joehu...@huawei.com wrote: Dear all TC PTL, In the 40 minutes cross-project summit session “Approaches for scaling out”[1], almost 100 peoples attended the meeting, and the conclusion is that cells can not cover the use

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-11 Thread joehuang
vs. Cells – summit recap and move forward On 12/11/2014 04:02 AM, joehuang wrote: [joehuang] The major challenge for VDF use case is cross OpenStack networking for tenants. The tenant's VM/Volume may be allocated in different data centers geographically, but virtual network (L2/L3/FW/VPN/LB

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-11 Thread joehuang
. Cells – summit recap and move forward On 12/11/2014 04:02 AM, joehuang wrote: Hello, Russell, Many thanks for your reply. See inline comments. -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Thursday, December 11, 2014 5:22 AM To: openstack-dev

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - summit recap and move forward

2014-12-11 Thread joehuang
( joehuang ) From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Friday, December 12, 2014 8:17 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - summit recap and move forward On Thu, Dec 11, 2014 at 1:02 AM

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-11 Thread joehuang
Hello, Joshua, Sorry, my fault. You are right. I owe you two dollars. Best regards Chaoyi Huang ( joehuang ) -Original Message- From: Joshua Harlow [mailto:harlo...@outlook.com] Sent: Friday, December 12, 2014 9:47 AM To: OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - summit recap and move forward

2014-12-11 Thread joehuang
.* How would cascading support something like this? [joehuang] Just reminder you that the cascading works like a normal OpenStack, if it can be solved by one OpenStack instance, it should be feasible too in cascading through the self-similar mechanism used ( just treat the cascaded OpenStack

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-11 Thread joehuang
the private APIs, which commponents included communication between the components . Best Regards Chaoyi Huang ( joehuang ) -Original Message- From: Dan Smith [mailto:d...@danplanet.com] Sent: Friday, December 12, 2014 11:41 AM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-12 Thread joehuang
, these questions are only part of them. It would be the best if cells can address all challenges, then of course no need an adtional solution. Best regards Chaoyi Huang ( joehuang ) From: Andrew Laski [andrew.la...@rackspace.com] Sent: 13 December 2014 0:06 To: OpenStack

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-12 Thread joehuang
term ( for example, Kilo and L release )? Or we need more discussion to include it in the roadmap, then I would like to know how to do that. Best Regards Chaoyi Huang ( joehuang ) From: Russell Bryant [rbry...@redhat.com] Sent: 12 December 2014 22:50

[openstack-dev] RE: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells �C summit recap and move forward

2014-12-15 Thread joehuang
or not. Using global KeyStone makes the project ID/user/role/domain/group have consistentent view in the cloud. The token used in the request to cascading Nova/Cinder/Neutron will be transfered in the request to the cascaded Nova/Cinder/Neutron too. Best regards Chaoyi Huang ( joehuang

Re: [openstack-dev] Cross-Project meeting, Tue December 16th, 21:00 UTC

2014-12-16 Thread joehuang
] Cross-Project meeting, Tue December 16th, 21:00 UTC Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting Tuesday at 21:00 UTC, with the following agenda: * Next steps for cascading (joehuang) * Providing an alternative to shipping default config file (ttx

Re: [openstack-dev] [glance] Replication on image create

2015-01-18 Thread joehuang
(Replace the word synchronization to replication to reduce misunderstanding) I also recommend approach #2. For, approach #1, 1) You have to maintain a state machine if you want to replicate the image to 3 or more backend. 2) Not always 3 or more backend will be replicated successfully, unless

Re: [openstack-dev] About DVR limit

2015-01-15 Thread joehuang
routing will be implemented before that, 2 ) Full distributed SNAT or only provide multi-SNAT network nodes Best Regards Chaoyi Huang ( Joe Huang ) From: Vasudevan, Swaminathan (PNB Roseville) [mailto:swaminathan.vasude...@hp.com] Sent: Friday, January 16, 2015 12:56 AM To: joehuang; 龚永生 Cc

Re: [openstack-dev] About DVR limit

2015-01-14 Thread joehuang
To: joehuang; OpenStack Development Mailing List (not for usage questions); 龚永生 Subject: RE: [openstack-dev] About DVR limit Hi Joehuang, FIP today as of Juno can be both in centralized node (dvr_snat) and distributed “dvr” compute nodes. Thanks Swami From: joehuang [mailto:joehu...@huawei.com

Re: [openstack-dev] [glance] Replication on image create

2015-01-14 Thread joehuang
I also recommend approach #2. For, approach #1, 1) You have to maintain a state machine if you want to synchronize the image to 3 or more backend. 2) Not always 3 or more backend will be synchronized successfully, unless you make it like a transaction, it's hard to process the synchronization

Re: [openstack-dev] About DVR limit

2015-01-14 Thread joehuang
Roseville) Cc: joehuang; OpenStack Development Mailing List (not for usage questions) Subject: Re:RE: [openstack-dev] About DVR limit Hi, Swami, Joehuang, in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and it is in the namespace of qrouter-. but in dvr_snat node, it is 1

Re: [openstack-dev] About DVR limit

2015-01-13 Thread joehuang
Hi, Swami, I would like to know whether the FIP under DVR could be configured to distributed mode or central mode in Kilo, not find relevant information from http://specs.openstack.org/openstack/neutron-specs/. For example, it will be helpful for following FIP use cases: 1) FIP will be

Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size

2015-03-18 Thread joehuang
Huang ) From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, March 17, 2015 10:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size On 03/17/2015 02:51 AM, joehuang wrote: It's not reality to deploy KeyStone

Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size

2015-03-17 Thread joehuang
[mailto:ayo...@redhat.com] Sent: Monday, March 16, 2015 10:52 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size On 03/16/2015 05:33 AM, joehuang wrote: [Topic]: Huge token size Hello, As you may or may not be aware

Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size

2015-03-18 Thread joehuang
Huang ) From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, March 17, 2015 10:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size On 03/17/2015 02:51 AM, joehuang wrote: It's not reality to deploy KeyStone

[openstack-dev] [all] Million level scalability test report from cascading

2015-03-31 Thread joehuang
Hi, all, During the last cross project meeting[1][2] for the next step of OpenStack cascading solution[3], the conclusion of the meeting is OpenStack isn't ready for the project, and if he want's it ready sooner than later, joehuang needs to help make it ready by working on scaling being coded

Re: [openstack-dev] [all] Million level scalability test report from cascading

2015-04-01 Thread joehuang
. Best Regards Chaoyi Huang ( joehuang ) On 31 March 2015 at 22:05, joehuang joehu...@huawei.com wrote: Hi, all, During the last cross project meeting[1][2] for the next step of OpenStack cascading solution[3], the conclusion of the meeting is OpenStack isn't ready for the project

Re: [openstack-dev] [all] Million level scalability test report from cascading

2015-04-01 Thread joehuang
only found your reply through the mail list achieve : http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg49335.html Best Regards Chaoyi Huang ( joehuang ) On 31 March 2015 at 22:05, joehuang joehu...@huawei.com wrote: Hi, all, During the last cross project meeting[1][2

[openstack-dev] [all] Million level scalability test report from cascading

2015-03-31 Thread joehuang
Hi, all, During the last cross project meeting[1][2] for the next step of OpenStack cascading solution[3], the conclusion of the meeting is OpenStack isn't ready for the project, and if he want's it ready sooner than later, joehuang needs to help make it ready by working on scaling being coded

Re: [openstack-dev] Multi Region Designate

2015-03-23 Thread joehuang
Hi, Anik, Interesting idea. The use case is quite useful. One project called “Copper” in OPNFV also mentioned a similar use case “Geo-Diverse Load-Balanced Service Instance Deployment” here : https://wiki.opnfv.org/copper/use_cases Designate may help “Geo-Diverse Load-Balanced Service

Re: [openstack-dev] Multi Region Designate

2015-03-23 Thread joehuang
Hi, Anik, Interesting idea. The use case is quite useful. One project called “Copper” in OPNFV also mentioned a similar use case here : https://wiki.opnfv.org/copper/use_cases “a single (flat) external domain name space for floating IPs” could be the first step, multiple external domains may

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-13 Thread joehuang
Huang ) -Original Message- From: Joshua Harlow [mailto:harlo...@outlook.com] Sent: Monday, April 13, 2015 11:11 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints? joehuang wrote: Hi, Kevin and Joshua

Re: [openstack-dev] [all] [cross-project] Any Openstack partitioning movements in this summit?

2015-04-29 Thread joehuang
Hi, Loy, +100. Really interesting topic. Cascading[1] has holistic thinking on the question list, and one cross project topic is just submitted yesterday: a) Any other value for partitioning besides scalability? e.g. fault domain isolation, heterogeneous integration... Sure, each cascaded

[openstack-dev] Technical vision for OpenStack to be ubiquitous cloud service

2015-04-28 Thread joehuang
Hello, all, This is Chaoyi Huang (Joe Huang). I am not TC, nor TC candidate, but I have a technical vision for OpenStack to be ubiquitous cloud service. I would like to apply one cross project session in the Vancouver design summit to give a lightning talk for the vision, TC/TC

Re: [openstack-dev] [neutron] Lightning Talks for the Design Summit

2015-05-11 Thread joehuang
and don'ts: Unit, functional, full-stack, API and Tempest (amuller) Neutron cascading to address scalability (joehuang) ML2 MechanismDrivers for bare-metal deployments (Sukhdev) Stateful OpenFlow Firewall Driver (ajo) distributed data-plane performance testing with Shakar (obondarev) multi-node

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-15 Thread joehuang
@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints? Hi again Joe, (+ list) On 11/04/15 02:00, joehuang wrote: Hi, Neil, See inline comments. Best Regards Chaoyi Huang From: Neil Jerram [neil.jer...@metaswitch.com] Sent

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-16 Thread joehuang
needed to achieve that? (e.g. api_workers and rpc_workers) Regards, Neil On 16/04/15 03:03, joehuang wrote: In case it's helpful to see all the cases together, sync_routers (from the L3 agent) was also mentioned in other part of this thread. Plus of course the liveness reporting from

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-17 Thread joehuang
the information here: https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Use_Case Best Regards Chaoyi Huang ( joehuang ) -Original Message- From: Attila Fazekas [mailto:afaze...@redhat.com] Sent: Thursday, April 16, 2015 3:06 PM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-13 Thread joehuang
-Original Message- From: Attila Fazekas [mailto:afaze...@redhat.com] Sent: Monday, April 13, 2015 3:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints? - Original Message - From: joehuang

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-12 Thread joehuang
Hi, Kevin and Joshua, As my understanding, Tooz only addresses the issue of agent status management, but how to solve the concurrent dynamic load impact on large scale ( for example 100k managed nodes with the dynamic load like security goup rule update, routers_updated, etc ) And one more

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-12 Thread joehuang
to take care of the port number limitation, there are so many agents will require connection concurrently, 100k level, and the requests can not be rejected. Best Regards Chaoyi Huang ( joehuang ) From: Kevin Benton [blak...@gmail.com] Sent: 12 April 2015 9

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-15 Thread joehuang
] [neutron] Neutron scaling datapoints? Hi Joe, Many thanks for your reply! On 09/04/15 03:34, joehuang wrote: Hi, Neil, From theoretic, Neutron is like a broadcast domain

Re: [openstack-dev] 答复: [neutron] Neutron scaling datapoints?

2015-04-15 Thread joehuang
PM Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints? Hi Joe, Many thanks for your reply! On 09/04/15 03:34, joehuang wrote: Hi, Neil, From theoretic

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-11 Thread joehuang
number of extra controller machine. Best Regards Chaoyi Huang ( joehuang ) From: Kevin Benton [blak...@gmail.com] Sent: 11 April 2015 12:34 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Neutron

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-10 Thread joehuang
datapoints? Hi Joe, Many thanks for your reply! On 09/04/15 03:34, joehuang wrote: Hi, Neil, From theoretic, Neutron is like a broadcast domain, for example, enforcement of DVR and security group has to touch each regarding host where there is VM of this project resides. Even using SDN

Re: [openstack-dev] Neutron scaling datapoints?

2015-04-10 Thread joehuang
Hi, Attlia, Interesting idea. Can you show us your test (or simulation test) result that Neutron can support up to 100k managed node. Best Regards Chaoyi Huang ( joehuang ) From: Attila Fazekas [afaze...@redhat.com] Sent: 10 April 2015 17:18

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

2015-04-08 Thread joehuang
Hi, Neil, From theoretic, Neutron is like a broadcast domain, for example, enforcement of DVR and security group has to touch each regarding host where there is VM of this project resides. Even using SDN controller, the touch to regarding host is inevitable. If there are plenty of physical

Re: [openstack-dev] [opnfv-tech-discuss] [Tricircle] Polling for weekly team meeting

2015-06-06 Thread joehuang
on the tricircle from scratch, with a PoC as reference. Best regards Chaoyi Huang ( joehuang ) From: opnfv-tech-discuss-boun...@lists.opnfv.org [opnfv-tech-discuss-boun...@lists.opnfv.org] on behalf of Rodriguez, Iben [iben.rodrig...@spirent.com] Sent: 05 June 2015 23

Re: [openstack-dev] [opnfv-tech-discuss] [Tricircle] Polling for weekly team meeting

2015-06-06 Thread joehuang
+1 Really funny, and helpful for innovation. Best Regards Chaoyi Huang ( joehuang ) From: opnfv-tech-discuss-boun...@lists.opnfv.org [opnfv-tech-discuss-boun...@lists.opnfv.org] on behalf of Daniel Smith [daniel.sm...@ericsson.com] Sent: 06 June 2015 21:35

[openstack-dev] [swift] Swift as Glance backend in multi-region scenario

2015-06-08 Thread joehuang
Hello, Swifter, It's often recommended to use shared Glance service with shared Swift as the backend to support image replication in multi-sites. The question is how many sites Swift can support to work as the image store? Is there any limitation on the multi-site image replication? Can Swift

Re: [openstack-dev] [Tricircle]New branch added

2015-06-25 Thread joehuang
Hi, We just tested that OpenStack API response is not very fast. From nova-client, if a boot-vm request is issued to Nova, it takes about 1.9 seconds to get the response. (The token format is UUID). Query is short, but it still take about 0.9 second. Best Regards Chaoyi Huang ( Joe Huang )

Re: [openstack-dev] [Tricircle] Ubernetes and Tricirle

2015-06-26 Thread joehuang
( Joe Huang ) From: Zhipeng Huang [mailto:zhipengh...@gmail.com] Sent: Saturday, June 27, 2015 8:20 AM To: OpenStack Development Mailing List (not for usage questions) Cc: joehuang; Eran Gampel; caizhiyuan (A); Gal Sagie; Saggi Mizrahi Subject: [openstack-dev][Tricircle] Ubernetes and Tricirle Hi

Re: [openstack-dev] [ceilometer][all] Scalable metering

2015-05-26 Thread joehuang
Hello, My idea for Ceilometer scaling is to partition Ceilometer based on project ID ( Sorry I am newbie to Ceilometer, correct me if I am wrong ). Why? 1. Each tenant only cares about the metering data/event/alarm for himself, doesn't cares who else is also using the ceilometers. Project ID

[openstack-dev] [Keystone][Fernet]multisite identity service management

2015-08-02 Thread joehuang
Hi, Glad to know you guys are talking about the key distribution and rotation for Fernet token. Hans and I did a prototype for multisite identity service management, and have a similar issue. The use case is : a user should, using a single authentication point be able to manage virtual

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

2015-07-30 Thread joehuang
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

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

2015-08-05 Thread joehuang
Hi, Lance, May we store the keys in Barbican, can the key rotation be done upon Barbican? And if we use Barican as the repository, then it’s easier for Key distribution and rotation in multiple KeyStone deployment scenario, the database replication (sync. or async.) capability could be

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

2015-08-03 Thread joehuang
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

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

2015-07-31 Thread joehuang
address, then ends the session at the end. BR Zhiyuan On 31 July 2015 at 09:05, joehuang joehu...@huawei.commailto:joehu...@huawei.com 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

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

2015-08-06 Thread joehuang
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 joehu...@huawei.commailto:joehu...@huawei.com wrote: Hi, In the PoC, the status

  1   2   3   4   5   >