<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">+1<o:p></o:p></p>
<p>-----Original Message-----<br>
From: Nikhil Komawar [mailto:nik.komawar@gmail.com] <br>
Sent: Monday, June 20, 2016 10:37 AM<br>
To: OpenStack Development Mailing List (not for usage questions) <br>
Subject: Re: [openstack-dev] [all] Proposal: Architecture Working Group<br>
<br>
+1 , great idea.<br>
<br>
if we can add a mission/objective based on the nice definitions you added, will help a long way in cross-project architecture evolution.<br>
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.<br>
<br>
On 6/17/16 5:52 PM, Clint Byrum wrote:<br>
> ar·chi·tec·ture<br>
> ˈärkəˌtek(t)SHər/<br>
> noun<br>
> noun: architecture<br>
><br>
> 1. <br>
><br>
> the art or practice of designing and constructing buildings.<br>
><br>
> synonyms:building design, building style, planning, building, <br>
> construction;<br>
><br>
> formalarchitectonics<br>
><br>
> "modern architecture"<br>
><br>
> the style in which a building is designed or constructed, especially with regard to a specific period, place, or culture.<br>
><br>
> plural noun: architectures<br>
><br>
> "Victorian architecture"<br>
><br>
> 2. <br>
><br>
> the complex or carefully designed structure of something.<br>
><br>
> "the chemical architecture of the human brain"<br>
><br>
> the conceptual structure and logical organization of a computer or computer-based system.<br>
><br>
> "a client/server architecture"<br>
><br>
> synonyms:structure, construction, organization, layout, design, <br>
> build, anatomy, makeup;<br>
><br>
> informalsetup<br>
><br>
> "the architecture of a computer system"<br>
><br>
><br>
> Introduction<br>
> =========<br>
><br>
> OpenStack is a big system. We have debated what it actually is [1], <br>
> and there are even t-shirts to poke fun at the fact that we don't have <br>
> good answers.<br>
><br>
> But this isn't what any of us wants. We'd like to be able to point at <br>
> something and proudly tell people "This is what we designed and <br>
> implemented."<br>
><br>
> And for each individual project, that is a possibility. Neutron can <br>
> tell you they designed how their agents and drivers work. Nova can <br>
> tell you that they designed the way conductors handle communication <br>
> with API nodes and compute nodes. But when we start talking about how <br>
> they interact with each other, it's clearly just a coincidental mash <br>
> of de-facto standards and specs that don't help anyone make decisions <br>
> when refactoring or adding on to the system.<br>
><br>
> Oslo and cross-project initiatives have brought some peace and order <br>
> to the implementation and engineering processes, but not to the design <br>
> process. New ideas still start largely in the project where they are <br>
> needed most, and often conflict with similar decisions and ideas in <br>
> other projects [dlm, taskflow, tooz, service discovery, state <br>
> machines, glance tasks, messaging patterns, database patterns, etc. <br>
> etc.]. Often times this creates a log jam where none of the projects <br>
> adopt a solution that would align with others. Most of the time when <br>
> things finally come to a head these things get done in a piecemeal <br>
> fashion, where it's half done here,<br>
> 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside <br>
> looks like chaos, because that's precisely what it is.<br>
><br>
> And this isn't always a technical design problem. OpenStack, for <br>
> instance, isn't really a micro service architecture. Of course, it <br>
> might look like that in diagrams [2], but we all know it really isn't. <br>
> The compute node is home to agents for every single concern, and the <br>
> API interactions between the services is too tightly woven to consider <br>
> many of them functional without the same lockstep version of other <br>
> services together. A game to play is ask yourself what would happen if <br>
> a service was isolated on its own island, how functional would its API <br>
> be, if at all. Is this something that we want? No. But there doesn't <br>
> seem to be a place where we can go to actually design, discuss, <br>
> debate, and ratify changes that would help us get to the point of <br>
> gathering the necessary will and capability to enact these efforts.<br>
><br>
> Maybe nova-compute should be isolated from nova, with an API that <br>
> nova, cinder and neutron talk to. Maybe we should make the scheduler <br>
> cross-project aware and capable of scheduling more than just nova <br>
> instances. Maybe we should have experimental groups that can look at <br>
> how some of this functionality could perhaps be delegated to <br>
> non-openstack projects. We hear that Mesos, for example to help with <br>
> the scheduling aspects, but how do we discuss these outside hijacking <br>
> threads on the mailing list? These are things that we all discuss in <br>
> the hallways and bars and parties at the summit, but because they <br>
> cross projects at the design level, and are inherently a lot of social <br>
> and technical and exploratory work, Many of us fear we never get to a <br>
> place of turning our dreams into reality.<br>
><br>
> So, with that, I'd like to propose the creation of an Architecture <br>
> Working Group. This group's charge would not be design by committee, <br>
> but a place for architects to share their designs and gain support <br>
> across projects to move forward with and ratify architectural <br>
> decisions. That includes coordinating exploratory work that may turn <br>
> into being the base of further architectural decisions for OpenStack. <br>
> I would expect that the people in this group would largely be senior <br>
> at the companies involved and, if done correctly, they can help <br>
> prioritize this work by advocating for people/fellow engineers to <br>
> actually make it 'real'. This will give weight to specs and <br>
> implementation changes to make these designs a reality, and thus I <br>
> believe this group would do well to work closely with the Oslo Team, where many of the cross-cutting efforts will need to happen.<br>
><br>
> How to get involved<br>
> ===================<br>
><br>
> If the idea is well received, I'd like to propose a bi-weekly IRC <br>
> meeting at a time convenient for the most interested individuals. I'd <br>
> also like to see a #openstack-architecture channel for gathering real <br>
> time chatter about architecture, and an architecture tag. Finally, I'd <br>
> like to see this group collaborate on direct work using the existing <br>
> openstack-specs repository.<br>
><br>
> In closing<br>
> ==========<br>
><br>
> First, thanks for reading this whole message and considering this <br>
> evolution of our processes. I am excited to begin this discussion, and <br>
> hope that we can arrive at a plan quickly that leads to us all being <br>
> able to discuss the architecture of OpenStack productively.<br>
><br>
> Also, thanks to those of you who helped me review and edit this document.<br>
><br>
> [1] <br>
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095452.htm<br>
> l [2] <br>
> http://docs.openstack.org/admin-guide/_images/openstack-arch-kilo-logi<br>
> cal-v1.png<br>
><br>
> ______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
<br>
-- <br>
<br>
Thanks,<br>
Nikhil<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<o:p></o:p></p>
</div>
</body>
</html>