[openstack-dev] [all]Architecture Working Group
joehuang at huawei.com
Mon Aug 1 06:39:16 UTC 2016
How are you, eager to know the plan and agenda for the Architecture Working Group, and would like to join the group, thanks.
And also leave a comment in the "Propose creation of Architecture Working Group" https://review.openstack.org/#/c/335141/ .
Chaoyi Huang (joehuang)
Sent: 25 July 2016 7:15
Cc: thierry at openstack.org
Subject: re: [openstack-dev] [all] Proposal: Architecture Working Group
Thanks to intiate the architecture working group, would be glad to join the group if there is still a place to stand.
According to the comment from Thierry in the Tricircle big-tent application https://review.openstack.org/#/c/338796/: "From an OpenStack community standpoint, we need more agreement and consensus on how we want to tackle the "massive scaling" issues. Tactical solutions like Nova cells only work for one project. I hope that the newly-founded Architecture WG can openly discuss an architecture for scaling OpenStack clouds beyond their current limits, a vision we can all get behind.
This is not a technical reflection on the quality of the Tricircle work. I think it's very interesting, I think the project should continue experimenting with the solution and I definitely want the Architecture WG to consider the Tricircle approach to scaling of using a top cell, API proxies and helpers. If anything, it forces us into having a discussion we should have had a long time ago, and for that I'm grateful that it was proposed."
So kindly please put the scaling OpenStack clouds in the agenda items, and also take these use cases into consideration: https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/edit?usp=sharing, i.e, let's discuss how to scale OpenStack clouds into one site or multiple sites.
Thank you all in advance.
Chaoyi Huang ( joehuang )
[openstack-dev] [all] Proposal: Architecture Working Group
Clint Byrum clint at fewbar.com <mailto:openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5Ball%5D%20Proposal%3A%20Architecture%20Working%20Group&In-Reply-To=%3C1466200248-sup-7094%40fewbar.com%3E>
Fri Jun 17 21:52:43 UTC 2016
* Previous message: [openstack-dev] OpenStack Developer Mailing List Digest May 14 to June 17<http://lists.openstack.org/pipermail/openstack-dev/2016-June/097667.html>
* Next message: [openstack-dev] [all] Proposal: Architecture Working Group<http://lists.openstack.org/pipermail/openstack-dev/2016-June/097674.html>
* Messages sorted by: [ date ]<http://lists.openstack.org/pipermail/openstack-dev/2016-June/date.html#97668> [ thread ]<http://lists.openstack.org/pipermail/openstack-dev/2016-June/thread.html#97668> [ subject ]<http://lists.openstack.org/pipermail/openstack-dev/2016-June/subject.html#97668> [ author ]<http://lists.openstack.org/pipermail/openstack-dev/2016-June/author.html#97668>
the art or practice of designing and constructing buildings.
synonyms:building design, building style, planning, building, construction;
the style in which a building is designed or constructed, especially with regard to a specific period, place, or culture.
plural noun: architectures
the complex or carefully designed structure of something.
"the chemical architecture of the human brain"
the conceptual structure and logical organization of a computer or computer-based system.
"a client/server architecture"
synonyms:structure, construction, organization, layout, design, build, anatomy, makeup;
"the architecture of a computer system"
OpenStack is a big system. We have debated what it actually is ,
and there are even t-shirts to poke fun at the fact that we don't have
But this isn't what any of us wants. We'd like to be able to point
at something and proudly tell people "This is what we designed and
And for each individual project, that is a possibility. Neutron can
tell you they designed how their agents and drivers work. Nova can
tell you that they designed the way conductors handle communication
with API nodes and compute nodes. But when we start talking about how
they interact with each other, it's clearly just a coincidental mash of
de-facto standards and specs that don't help anyone make decisions when
refactoring or adding on to the system.
Oslo and cross-project initiatives have brought some peace and order
to the implementation and engineering processes, but not to the design
process. New ideas still start largely in the project where they are
needed most, and often conflict with similar decisions and ideas in other
projects [dlm, taskflow, tooz, service discovery, state machines, glance
tasks, messaging patterns, database patterns, etc. etc.]. Often times this
creates a log jam where none of the projects adopt a solution that would
align with others. Most of the time when things finally come to a head
these things get done in a piecemeal fashion, where it's half done here,
1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
looks like <architecture> chaos, because that's precisely what it is.
And this isn't always a technical design problem. OpenStack, for instance,
isn't really a micro service architecture. Of course, it might look like
that in diagrams , but we all know it really isn't. The compute node is
home to agents for every single concern, and the API interactions between
the services is too tightly woven to consider many of them functional
without the same lockstep version of other services together. A game to
play is ask yourself what would happen if a service was isolated on its
own island, how functional would its API be, if at all. Is this something
that we want? No. But there doesn't seem to be a place where we can go
to actually design, discuss, debate, and ratify changes that would help
us get to the point of gathering the necessary will and capability to
enact these efforts.
Maybe nova-compute should be isolated from nova, with an API that
nova, cinder and neutron talk to. Maybe we should make the scheduler
cross-project aware and capable of scheduling more than just nova
instances. Maybe we should have experimental groups that can look at how
some of this functionality could perhaps be delegated to non-openstack
projects. We hear that Mesos, for example to help with the scheduling
aspects, but how do we discuss these outside hijacking threads on the
mailing list? These are things that we all discuss in the hallways
and bars and parties at the summit, but because they cross projects at
the design level, and are inherently a lot of social and technical and
exploratory work, Many of us fear we never get to a place of turning
our dreams into reality.
So, with that, I'd like to propose the creation of an Architecture Working
Group. This group's charge would not be design by committee, but a place
for architects to share their designs and gain support across projects
to move forward with and ratify architectural decisions. That includes
coordinating exploratory work that may turn into being the base of further
architectural decisions for OpenStack. I would expect that the people
in this group would largely be senior at the companies involved and,
if done correctly, they can help prioritize this work by advocating for
people/fellow engineers to actually make it 'real'. This will give weight
to specs and implementation changes to make these designs a reality,
and thus I believe this group would do well to work closely with the
Oslo Team, where many of the cross-cutting efforts will need to happen.
How to get involved
If the idea is well received, I'd like to propose a bi-weekly IRC
meeting at a time convenient for the most interested individuals. I'd
also like to see a #openstack-architecture channel for gathering real
time chatter about architecture, and an architecture tag. Finally, I'd
like to see this group collaborate on direct work using the existing
First, thanks for reading this whole message and considering this
evolution of our processes. I am excited to begin this discussion, and
hope that we can arrive at a plan quickly that leads to us all being
able to discuss the architecture of OpenStack productively.
Also, thanks to those of you who helped me review and edit this document.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev