Open Stack

+1

-----Original Message-----
From: Nikhil Komawar [mailto:nik.komawar at gmail.com]
Sent: Monday, June 20, 2016 10:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] Proposal: Architecture Working Group

+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 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.htm
> l [2]
> http://docs.openstack.org/admin-guide/_images/openstack-arch-kilo-logi
> cal-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


__________________________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160701/61f9684f/attachment.html>