Open Stack

On 14/07/2016 21:20, Matt Riedemann wrote:
> On 7/14/2016 2:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>> It undoubtedly will cause more, but it is closer to our goal
>> of Recognizing all our community is part of OpenStack, and
>> differentiate projects by tags.
>>
>> This won't be a change that happens tomorrow, next week, or even next
>> cycle, but think as a goal, we should start moving in this direction
>> as soon as we can, and start building momentum.
>>
>> Thanks,
>>
>> Graham
>>
>> 0 - https://review.openstack.org/342366
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Just for my own understanding, are you suggesting that something like
> nova, cinder or neutron become optional for an openstack cloud?

Not in this proposal. (but that is an interesting idea we should follow
up on at a later date)

> And does this also include plugins within projects, like storage
> backends in cinder and hypervisor drivers in nova?

This is aimed at cross project interaction. So, if there is a project in
projects.yaml that is a backend, or a hypervisor driver, it should.

However, in the proposal, there is a choice that projects can make -
all in tree, or all plugins. The point of the proposal is equality of
access for the community.

What would that mean in practice for Nova? Nothing would really change
- they have decided to do in tree.

99% of deliverables tagged type:service will have no impact from this,
the change will be in projects that are used by  teams across the
community (CLI, Docs, UI etc), and provide a way for these projects
to integrate with them.

These integration points should be the same for *all* projects.

> Nova has been pushing for a few releases now on getting rid of plug
> points since they are barriers to interoperability.

Well, nova's plugins were barriers to interoperability, for other
projects they are the only mechanism for interoperability.