Re: [openstack-dev] [tricircle] weekly meeting of Dec.16
Hi, Sorry that the network connection problem stopped me attending the meeting. Hope that we can arrive at the phase 1 milestone in the todo-list by the end of this week. Best Regards Chaoyi Huang ( joehuang ) From: joehuang Sent: 16 December 2015 14:05 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle] weekly meeting of Dec.16 Hi, Let’s have regular meeting today starting UTC1300 at #openstack-meeting Agenda: Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo Discussion of stateless design. Best Regards Chaoyi Huang ( Joe Huang ) From: joehuang [mailto:joehu...@huawei.com] Sent: Tuesday, December 08, 2015 1:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle]Stateless design proposal for Tricircle project Hi, Managing multiple instances of OpenStack is a headache. Each OpenStack instance is individual silo, with its separate resources, networks, images, etc. Tricircle, the project aiming to address this headache, a Top (aka cascading) minimalist "OpenStack instance" will manages multiple Bottom (aka cascaded) OpenStack instances. The top will expose OpenStack API to embrace all eco-system built upon OpenStack API. This model and its value has been verified in several production clouds. Now one stateless design for the Tricircle, the top minimalist "OpenStack instance", is just proposed in the doc [1]: The stateless design introduce several components, and fully decoupled with OpenStack services like Nova, Cinder, and the Tricircle plugin will work just like OVN, ODL plugin in Neutron project, the design also try to remove the uuid mapping, status synchronization challenges. • Admin API manage sites(bottom OpenStack instances) and availability zone mapping retrieve object uuid routing expose api for maintenance • Nova API-GW an standalone web service to receive all nova api request, and routing the request to regarding bottom OpenStack according to Availability Zone ( during creation ) or resource id ( during operation and query ). work as stateless service, and could run with processes distributed in multi-hosts. • Cinder API-GW an standalone web service to receive all cinder api request, and routing the request to regarding bottom OpenStack according to Availability Zone ( during creation ) or resource id ( during operation and query ). work as stateless service, and could run with processes distributed in multi-hosts. • XJob receive and process cross OpenStack functionalities and other async. jobs from message bus for example, when booting a VM for the first time for the project, router, security group rule, FIP and other resources may have not already been created in the bottom site, but it’s required. Not like network, security group, ssh key etc resources they must be created before a VM booting, these resources could be created in async.way to accelerate response for the first VM booting request cross OpenStack networking also will be done in async. jobs Any of Admin API, Nova API-GW, Cinder API-GW, Neutron Tricircle plugin could send an async. job to XJob through message bus with RPC API provided by XJob • Neutron Tricircle plugin Just like OVN, ODL Neutron plugin, the tricircle plugin serve for multi-site networking purpose, including interaction with DCI SDN controller, will use ML2 mechanism driver interface to call DCI SDN controller, especially for cross OpenStack provider multi-segment L2 networking. • DB Tricircle can have its own database to store sites, fake nodes, availability zone mapping, jobs, resource routing table A plan to do PoC for this idea is working on the experiment branch of Tricircle [2][4], once the result give us positive feedback, the work will be moved to the master branch. Welcome to join the adventure, contribute your power in the review, design writing source code, maintaining infrastructure, testing, bug fix, the weekly meeting[3]..., all work just starts[4]. [1] design doc: https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g [2] Stateless design branch: https://github.com/openstack/tricircle/tree/experiment [3] weekly meeting: #openstack-meeting on every Wednesday starting from UTC 13:00 [4] To do list is in the etherpad: https://etherpad.openstack.org/p/TricircleToDo Best Regards Chaoyi Huang ( Joe Huang ) From: joehuang Sent: Wednesday, December 02, 2015 2:37 PM To: 'Zhipeng Huang'; OpenStack Development Mailing List (not for usage questions); caizhiyuan (A); Irena Berezovsky; Orran Krieger; Mohammad Badruzzaman; 홍석찬 Subject: [openstack-dev][tricircle] weekly meeting of Dec.2 Hi, Let’s have regular meeting today starting UTC1300 at #openstack-meeting. The networking proposal is updated in the document, and a proposal for stateless PoC also was updat
[openstack-dev] [tricircle] weekly meeting of Dec.16
Hi, Let’s have regular meeting today starting UTC1300 at #openstack-meeting Agenda: Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo Discussion of stateless design. Best Regards Chaoyi Huang ( Joe Huang ) From: joehuang [mailto:joehu...@huawei.com] Sent: Tuesday, December 08, 2015 1:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle]Stateless design proposal for Tricircle project Hi, Managing multiple instances of OpenStack is a headache. Each OpenStack instance is individual silo, with its separate resources, networks, images, etc. Tricircle, the project aiming to address this headache, a Top (aka cascading) minimalist "OpenStack instance" will manages multiple Bottom (aka cascaded) OpenStack instances. The top will expose OpenStack API to embrace all eco-system built upon OpenStack API. This model and its value has been verified in several production clouds. Now one stateless design for the Tricircle, the top minimalist "OpenStack instance", is just proposed in the doc [1]: The stateless design introduce several components, and fully decoupled with OpenStack services like Nova, Cinder, and the Tricircle plugin will work just like OVN, ODL plugin in Neutron project, the design also try to remove the uuid mapping, status synchronization challenges. • Admin API manage sites(bottom OpenStack instances) and availability zone mapping retrieve object uuid routing expose api for maintenance • Nova API-GW an standalone web service to receive all nova api request, and routing the request to regarding bottom OpenStack according to Availability Zone ( during creation ) or resource id ( during operation and query ). work as stateless service, and could run with processes distributed in multi-hosts. • Cinder API-GW an standalone web service to receive all cinder api request, and routing the request to regarding bottom OpenStack according to Availability Zone ( during creation ) or resource id ( during operation and query ). work as stateless service, and could run with processes distributed in multi-hosts. • XJob receive and process cross OpenStack functionalities and other async. jobs from message bus for example, when booting a VM for the first time for the project, router, security group rule, FIP and other resources may have not already been created in the bottom site, but it’s required. Not like network, security group, ssh key etc resources they must be created before a VM booting, these resources could be created in async.way to accelerate response for the first VM booting request cross OpenStack networking also will be done in async. jobs Any of Admin API, Nova API-GW, Cinder API-GW, Neutron Tricircle plugin could send an async. job to XJob through message bus with RPC API provided by XJob • Neutron Tricircle plugin Just like OVN, ODL Neutron plugin, the tricircle plugin serve for multi-site networking purpose, including interaction with DCI SDN controller, will use ML2 mechanism driver interface to call DCI SDN controller, especially for cross OpenStack provider multi-segment L2 networking. • DB Tricircle can have its own database to store sites, fake nodes, availability zone mapping, jobs, resource routing table A plan to do PoC for this idea is working on the experiment branch of Tricircle [2][4], once the result give us positive feedback, the work will be moved to the master branch. Welcome to join the adventure, contribute your power in the review, design writing source code, maintaining infrastructure, testing, bug fix, the weekly meeting[3]..., all work just starts[4]. [1] design doc: https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g [2] Stateless design branch: https://github.com/openstack/tricircle/tree/experiment [3] weekly meeting: #openstack-meeting on every Wednesday starting from UTC 13:00 [4] To do list is in the etherpad: https://etherpad.openstack.org/p/TricircleToDo Best Regards Chaoyi Huang ( Joe Huang ) From: joehuang Sent: Wednesday, December 02, 2015 2:37 PM To: 'Zhipeng Huang'; OpenStack Development Mailing List (not for usage questions); caizhiyuan (A); Irena Berezovsky; Orran Krieger; Mohammad Badruzzaman; 홍석찬 Subject: [openstack-dev][tricircle] weekly meeting of Dec.2 Hi, Let’s have regular meeting today starting UTC1300 at #openstack-meeting. The networking proposal is updated in the document, and a proposal for stateless PoC also was updated in the doc. https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit?usp=sharing Best Regards Chaoyi Huang ( Joe Huang ) From: Zhipeng Huang [mailto:zhipengh...@gmail.com] Sent: Wednesday, November 25, 2015 5:44 PM To: OpenStack Development Mailing List (not for usage questions); joehuang; caizhiyuan (A); Irena Berezovsky; Orran Krieger; Mohammad Badruzzaman; 홍석찬 Subject: Re: [openstack-dev][tricircle]Tokyo Summit
