<div dir="ltr">Hello Clint.<div><br></div><div>I'd like to take part as well, so count me in.</div><div><br></div><div>Kind regards,</div><div>Denys Makogon</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-20 10:23 GMT+03:00 Ghe Rivero <span dir="ltr"><<a href="mailto:ghe.rivero@gmail.com" target="_blank">ghe.rivero@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br>
    I really like the idea of the group, so count me in!<br>
<br>
Ghe Rivero<br>
<br>
Quoting Clint Byrum (2016-06-17 23:52:43)<br>
<div class="HOEnZb"><div class="h5">> 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, 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, 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<br>
> at 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 of<br>
> de-facto standards and specs that don't help anyone make decisions when<br>
> 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 other<br>
> projects [dlm, taskflow, tooz, service discovery, state machines, glance<br>
> tasks, messaging patterns, database patterns, etc. etc.]. Often times this<br>
> creates a log jam where none of the projects adopt a solution that would<br>
> align with others. Most of the time when things finally come to a head<br>
> these things get done in a piecemeal 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 <architecture> chaos, because that's precisely what it is.<br>
><br>
> And this isn't always a technical design problem. OpenStack, for instance,<br>
> isn't really a micro service architecture. Of course, it might look like<br>
> that in diagrams [2], but we all know it really isn't. The compute node is<br>
> home to agents for every single concern, and the API interactions between<br>
> the services is too tightly woven to consider many of them functional<br>
> without the same lockstep version of other services together. A game to<br>
> play is ask yourself what would happen if a service was isolated on its<br>
> own island, how functional would its API be, if at all. Is this something<br>
> that we want? No. But there doesn't seem to be a place where we can go<br>
> to actually design, discuss, debate, and ratify changes that would help<br>
> us get to the point of gathering the necessary will and capability to<br>
> 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 how<br>
> some of this functionality could perhaps be delegated to non-openstack<br>
> projects. We hear that Mesos, for example to help with the scheduling<br>
> aspects, but how do we discuss these outside hijacking threads on the<br>
> mailing list? These are things that we all discuss in the hallways<br>
> and bars and parties at the summit, but because they cross projects at<br>
> the design level, and are inherently a lot of social and technical and<br>
> exploratory work, Many of us fear we never get to a place of turning<br>
> our dreams into reality.<br>
><br>
> So, with that, I'd like to propose the creation of an Architecture Working<br>
> Group. This group's charge would not be design by committee, but a place<br>
> for architects to share their designs and gain support across projects<br>
> to move forward with and ratify architectural decisions. That includes<br>
> coordinating exploratory work that may turn into being the base of further<br>
> architectural decisions for OpenStack. I would expect that the people<br>
> in this group would largely be senior at the companies involved and,<br>
> if done correctly, they can help prioritize this work by advocating for<br>
> people/fellow engineers to actually make it 'real'. This will give weight<br>
> to specs and implementation changes to make these designs a reality,<br>
> and thus I believe this group would do well to work closely with the<br>
> 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] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/095452.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/095452.html</a><br>
> [2] <a href="http://docs.openstack.org/admin-guide/_images/openstack-arch-kilo-logical-v1.png" rel="noreferrer" target="_blank">http://docs.openstack.org/admin-guide/_images/openstack-arch-kilo-logical-v1.png</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>