On Wed, 12 Apr 2017, joehuang wrote:
Can all these efforts lead us to one platform vision? We have to think over the question.What's the one platform will be in your own words? What's your proposal and your focus to help one platform vision being achieved?
These are tough questions. It's great to have a vision of one platform, but if there are multiple understandings of what that platform is (even when everyone thinks they are agreeing it's often the case that they are not), it will be very hard to make progress. At the same time inertia has enormous power to keep people, projects, and companies doing the same old thing. As usual, I think spending more effort to write down ideas, such as the TC Vision draft and its concept of constellations[1] and the resolution on cloud applications[2], are an important (but not fully sufficient) step. The documents provide a focus around which discussion can happen. While disagreement and enthusiasm are important indicators, at least as important is the degree to which people squirm about the assumptions being made. Writing helps to expose those assumptions and once exposed we can decide what to do with them. In order for us to move forward on the one platform idea we need to take the time and effort first to articulate the multiple approaches and second to convince people of their merit. This second step will require consistent engagement with not just project members but with the companies that are funding most contributors. Those companies have to be convinced of the merit of change. There's no doubt this will be challenging, especially in these times when some companies are willing to declare that OpenStack is "broken". Making progress will require a TC that is proactive. In the last election in October there were questions around whether the TC should be a "a reactive council" or "a proactive committee that initiates change"[3]. I'm firmly in the latter camp but believe the action must be driven by a very active feedback loop with the entire OpenStack community. In any case, I do have a personal vision. It could very well be far too pie in the sky and require too much change, but if approached incrementally could provide benefit. My hope is that lots of people would have a chance to express their vision and from all of them we would choose the best bits to form the vision that we pursue. Any vision will have many dependent tasks that must be satisfied before the vision can even start. For example common policy scenarios[4] and application user accounts[5] are global issues we will need to address. Essentially the idea is to change or expand the layers at which humans and external applications interact with OpenStack, in the style of oaktree[5] or enamel[6], where the outer layer is a single API service driven by use cases (give me a vm, give me a bare metal server, give me a pod representing elastic application X, orchestrate the assemblage of Y). That layer speaks to the service APIs to achieve its needs. Complex use cases (NFV perhaps?) might skip the outer layer when they require functionality that the outer layer does not expose. If the constellation metaphor catches on then it is also possible that different constellations might have different outer layers. Like so many technology solutions, this is "simply" introducing another layer of indirection. Doing so would enable each layer to evolve with some independence and, critically, would allow different implementations of the same service type to leapfrog an incumbent[7]. To use that hackneyed cliché: skate to where the puck will be. If we are going to be thinking of OpenStack as one platform, then we need to evaluate its various pieces with regard to how they support that platform and each other as a whole. The needs and goals of the individual services need to be secondary to the needs and goals of OpenStack at large. That's a huge change in behavior and attitude, one that might not be achievable, but worth trying. I've been around long enough to know that there are many objections to these kinds of changes, both technical and social. I think, however, that it is important to at least consider them so we can discover what improvements are possible. We're starting to recognize that OpenStack must evolve more quickly. In order to do that we must figure out ways to work around or loosen the constraints we've built into our process and ways of engaging new audiences. None of this is possible, however, unless the OpenStack community in general and the TC in particular is able to come up with an effective way to effectively publicize and manage the need for contributors and other resources. The increased writing described above will provide some help with that, but another important part will involve being very clear with all stakeholders about the sheer volume of work required to create and maintain OpenStack. [1] https://review.openstack.org/#/c/453262/ [2] https://review.openstack.org/#/c/447031/ [3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/104953.html [4] https://review.openstack.org/#/c/245629/ [5] https://github.com/openstack/oaktree [6] https://github.com/jaypipes/enamel [7] Note that I'm not suggesting here that a new implementation of a service type implement the same internal API. I'm saying there could be a new API and implementation that the outer layer would interface with to satisfy the same use cases using changed technologies. -- Chris Dent ¯\_(ツ)_/¯ https://anticdent.org/ freenode: cdent tw: @anticdent
__________________________________________________________________________ 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
