Open Stack

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; mordred at 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; mordred at 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 [mordred at 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_rq9TvkuczjommJSsisDiKJiurbhaQg7E,
>
> your thoughts are welcome, and let's have more discussion in this weekly
> meeting.

I think this is a great approach Joe.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160902/aa6d6c97/attachment.html>