Open Stack

+1 , great idea.

if we can add a mission/objective based on the nice definitions you
added, will help a long way in cross-project architecture evolution.
moreover, I'd like this to be a integration point for openstack projects
(and not a silo) so that we can build the shared understanding we really
need to build.

On 6/17/16 5:52 PM, Clint Byrum wrote:
> ar·chi·tec·ture
> ˈärkəˌtek(t)SHər/
> noun
> noun: architecture
>
>     1. 
>
>     the art or practice of designing and constructing buildings.
>
>     synonyms:building design, building style, planning, building, construction; 
>
>     formalarchitectonics 
>
>     "modern architecture"
>
>     the style in which a building is designed or constructed, especially with regard to a specific period, place, or culture.
>
>     plural noun: architectures
>
>     "Victorian architecture"
>
>     2. 
>
>     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; 
>
>     informalsetup 
>
>     "the architecture of a computer system"
>
>
> Introduction
> =========
>
> OpenStack is a big system. We have debated what it actually is [1],
> and there are even t-shirts to poke fun at the fact that we don't have
> good answers.
>
> 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
> implemented."
>
> 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 [2], 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
> openstack-specs repository.
>
> In closing
> ==========
>
> 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.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095452.html
> [2] http://docs.openstack.org/admin-guide/_images/openstack-arch-kilo-logical-v1.png
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil