+1 -----Original Message----- From: Nikhil Komawar [mailto:nik.koma...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev