<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 4:28 PM, Gregory Haynes <span dir="ltr"><<a href="mailto:greg@greghaynes.net" target="_blank">greg@greghaynes.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><div><div><div>On Mon, May 23, 2016, at 05:24 PM, Morgan Fainberg wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div> <br></div>
<div><div> <br></div>
<div><div>On Mon, May 23, 2016 at 2:57 PM, Gregory Haynes <span dir="ltr"><<a href="mailto:greg@greghaynes.net" target="_blank">greg@greghaynes.net</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div>On Fri, May 20, 2016, at 07:48 AM, Thierry Carrez wrote:<br></div>
<div>> John Dickinson wrote:<br></div>
<div>> > [...]<br></div>
<div>> >> So the real question we need to answer is... where does OpenStack<br></div>
<div>> >> stop, and where does the wider open source community start ? If<br></div>
<div>> >> OpenStack is purely an "integration engine", glue code for other<br></div>
<div>> >> lower-level technologies like hypervisors, databases, or distributed<br></div>
<div>> >> block storage, then the scope is limited, Python should be plenty<br></div>
<div>> >> enough, and we don't need to fragment our community. If OpenStack is<br></div>
<div>> >> "whatever it takes to reach our mission", then yes we need to add one<br></div>
<div>> >> language to cover lower-level/native optimization, because we'll<br></div>
<div>> >> need that... and we need to accept the community cost as a<br></div>
<div>> >> consequence of that scope choice. Those are the only two options on<br></div>
<div>> >> the table.<br></div>
<div>> >><br></div>
<div>> >> I'm actually not sure what is the best answer. But I'm convinced we,<br></div>
<div>> >> as a community, need to have a clear answer to that. We've been<br></div>
<div>> >> avoiding that clear answer until now, creating tension between the<br></div>
<div>> >> advocates of an ASF-like collection of tools and the advocates of a<br></div>
<div>> >> tighter-integrated "openstack" product. We have created silos and<br></div>
<div>> >> specialized areas as we got into the business of developing time-<br></div>
<div>> >> series databases or SDNs. As a result, it's not "one community"<br></div>
<div>> >> anymore. Should we further encourage that, or should we focus on<br></div>
<div>> >> what the core of our mission is, what we have in common, this<br></div>
<div>> >> integration engine that binds all those other open source projects<br></div>
<div>> >> into one programmable infrastructure solution ?<br></div>
<div>> ><br></div>
<div>> > You said the answer in your question. OpenStack isn't defined as an<br></div>
<div>> > integration engine[3]. The definition of OpenStack is whatever it<br></div>
<div>> > takes to fulfill our mission[4][5]. I don't mean that as a tautology.<br></div>
<div>> > I mean that we've already gone to the effort of defining OpenStack. It's<br></div>
<div>> > our mission statement. We're all about building a cloud platform upon<br></div>
<div>> > which people can run their apps ("cloud-native" or otherwise), so we<br></div>
<div>> > write the software needed to do that.<br></div>
<div>> ><br></div>
<div>> > So where does OpenStack stop and the wider community start? OpenStack<br></div>
<div>> > includes the projects needed to fulfill its mission.<br></div>
<div>><br></div>
<div>> I'd totally agree with you if OpenStack was developed in a vacuum. But<br></div>
<div>> there is a large number of open source projects and libraries that<br></div>
<div>> OpenStack needs to fulfill its mission that are not in "OpenStack": they<br></div>
<div>> are external open source projects we depend on. Python, MySQL, libvirt,<br></div>
<div>> KVM, Ceph, OpenvSwitch, RabbitMQ... We are not asking that those should<br></div>
<div>> be included in OpenStack, and we are not NIHing replacements for those<br></div>
<div>> in OpenStack either.<br></div>
<div>><br></div>
<div>> So it is not as clear-cut as you present it, and you can approach this<br></div>
<div>> dependency question from two directions.<br></div>
<div>><br></div>
<div>> One is community-centric: "anything produced by our community is<br></div>
<div>> OpenStack". If we are missing a lower-level piece to achieve our mission<br></div>
<div>> and are developing it ourselves as a result, then it is OpenStack, even<br></div>
<div>> if it ends up being a message queue or a database.<br></div>
<div>><br></div>
<div>> The other approach is product-centric: "lower-level pieces are OpenStack<br></div>
<div>> dependencies, rather than OpenStack itself". If we are missing a<br></div>
<div>> lower-level piece to achieve our mission and are developing it as a<br></div>
<div>> result, it could be developed on OpenStack infrastructure by members of<br></div>
<div>> the OpenStack community but it is not "OpenStack the product", it's an<br></div>
<div>> OpenStack *dependency*. It is not governed by the TC, it can use any<br></div>
<div>> language and tool deemed necessary.<br></div>
<div>><br></div>
<div>> On this second approach, there is the obvious question of where<br></div>
<div>> "lower-level" starts, which as you explained above is not really<br></div>
<div>> clear-cut. A good litmus test for it could be whenever Python is not<br></div>
<div>> enough. If you can't develop it effectively with the language that is<br></div>
<div>> currently sufficient for the rest of OpenStack, then developing it as an<br></div>
<div>> OpenStack dependency in whatever language is appropriate might be the<br></div>
<div>> solution...<br></div>
<div>><br></div>
<div>> That is what I mean by 'scope': where does "OpenStack" stop, and where<br></div>
<div>> do "OpenStack dependencies" start ? It is a lot easier and a lot less<br></div>
<div>> community-costly to allow additional languages in OpenStack dependencies<br></div>
<div>> (we already have plenty there).<br></div>
<div>><br></div>
<div> <br></div>
</div>
</div>
<div>I strongly agree with both of the points about what OpenStack is defined<br></div>
<div>as. We are  a set of projects attempting to fulfill our mission. In<br></div>
<div>doing so, we try to use outside dependencies to help us as much as<br></div>
<div>possible. Sometimes we cannot find an outside dependency to satisfy a<br></div>
<div>need whether due to optimization needs, licensing issues, usability<br></div>
<div>problems, or simply because an outside project doesn't exist. That is<br></div>
<div>when things become less clear-cut and we might need to develop software<br></div>
<div>not purely/directly related to fulfilling our mission.<br></div>
<div> <br></div>
<div>In the product-centric approach I worry that we are going to be paying<br></div>
<div>many of the costs which the existing TC resolutions hoped to prevent. We<br></div>
<div>still will have to maintain and debug these dependencies and if the<br></div>
<div>OpenStack community is the only ones doing so then the language<br></div>
<div>fragmentation costs will come in to play. Our goal should be to only pay<br></div>
<div>these costs when necessary, and I am not sure this type of distinction<br></div>
<div>helps us do that.<br></div>
<div> <br></div>
<div>Additionally, I am not sure how this would solve the swift case. The<br></div>
<div>object server is the component that has been rewritten so either it<br></div>
<div>would need to live outside of OpenStack with the rest of Swift being<br></div>
<div>part of OpenStack, or all of Swift would need to move outside. Neither<br></div>
<div>of these seems ideal.<br></div>
<div> <br></div>
<div>This makes me wonder - does this decision need to be an all-or-nothing<br></div>
<div>thing? Can we say that the swift object server is a special case, let it<br></div>
<div>be written in another language, and leave it at that? My thinking is -<br></div>
<div>there is only value in us deciding on and allowing an additional<br></div>
<div>language for solving these issues generally if there are other places<br></div>
<div>that require this new language. It has been mentioned that Gnocchi could<br></div>
<div>potentially be a case in the future but until that problem actually<br></div>
<div>comes up there isn't much benefit to us deciding on another language<br></div>
<div>anyone can use and there are plenty of downsides to doing so.<br></div>
<div> <br></div>
</blockquote><div> <br></div>
<div>I really do not want to "special case" swift. It really doesn't go with the spirit of inclusion.<br></div>
</div>
</div>
</div>
</blockquote><div> <br></div>
</div></div><div>I am not sure how inclusion is related to special casing. Inclusion here implies that some group is not being accepted in to our community. The excluded group here would be one writing software not in python, which is the same groups being excluded currently. This is an argument against the status quo, not against special casing.<br></div><span>
<div> <br></div>
<blockquote type="cite"><div dir="ltr"><div><div><div>I expect we will see a continued drive for whichever additional languages are supported once it's in place/allowed.<br></div>
</div>
</div>
</div>
</blockquote><div> <br></div>
</span><div>That is the problem. The social and debugging costs of adding another language are a function of how much that other language is used. If one component of one project is written in another language then these costs should be fairly low. I agree that once we allow another language we should expect many projects to begin using it, and IMO most if not all of these cases except swift will not be warranted. Thus, we will be paying the costs in development resources from several standpoints without cause.<br></div><span>
<div> <br></div>
<blockquote type="cite"><div dir="ltr"><div><div><div>I also worry "special casing" drives at a core thing we've been trying to dissuade: Swift is not a special case and is part of OpenStack. It should be considered as such and adding more onto that line just divides the community further.<br></div>
<div> <br></div>
<div>I think that filling the role of "native optimizations that are inappropriate in python" is something we will continue to have requests for especially if one project has blessing to use this native-tool-optimization-thing.<br></div>
<div> <br></div>
</div>
</div>
</div>
</blockquote><div> </div>
</span><div>This is my main disagreement with the all-or-nothing premise - we seem to have a bad case of fallacy of composition. AFAIK we do not have other components of OpenStack which are needing to do a read on a large number of on disk files in parallel from python, let alone do it in a highly performant way. Just because we have identified one non trivial problem for a language does not mean we have lots more to come. It is entirely possible that another project will have this same problem or we will identify another problem in the future which requires a similar solution, but I don't know why we expect to or even want to solve that issue now before that case is clearly defined. Hopefully we don't have the need to write more databases as part of OpenStack...<br></div><span>
<div> </div></span></div></blockquote><div><br></div><div>I am fine with this in premise, but I just want to be clear where I am coming from on  the inclusion of golang (or rust, or C++, or JavaScript, or Java, etc, etc). If we are accepting golang, I want it to be clearly documented that the expectation is it is used exclusively where there is a demonstrable case (such as with swift) and not a carte blanche to use it wherever-you-please.</div><div><br></div><div>I want this to be a social contract looked at and enforced by the community, not special permissions that are granted by the TC (I don't want the TC to need to step in an approve every single use case of golang, or javascript ...). It's bottlenecking back to the TC for special permissions or inclusion (see reasons for the dissolution of the "integrated release").</div><div><br></div><div>This isn't strictly an all or nothing case, this is a "how would we enforce this?" type deal. Lean on infra to enforce that only projects with the golang-is-ok-here tag are allowed to use it? I don't want people to write their APIs in javascript (and node.js) nor in golang. I would like to see most of the work continue with python as the primary language. I just think it's unreasonable to lock tools behind a gate that is stronger than the social / community contract (and outlined in the resolution including X language).</div><div><br></div><div>So, I'm not disagreeing with you, I am disagreeing with needing to grant special permissions to use a tool. If a project is doing something totally crazy, we can look into/address from the technical committee (and yes, writing your apis in golang for the sake of writing your apis in golang is somewhat crazy).</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span>
<blockquote type="cite"><div dir="ltr"><div><div><div>So in short, lets not special case a project here.<br></div>
<div> <br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Cheers,<br></div>
<div>Greg<br></div>
</blockquote></div>
</div>
</div>
</blockquote><div> </div>
</span><div>Cheers,<br></div>
<div>Greg</div>
</div>

<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></blockquote></div><br></div></div>