Open Stack

On 15/07/2016 17:10, Andrew Laski wrote:
>
>
> On Thu, Jul 14, 2016, at 03: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.
>
> Which internal APIs are you referring to here? Are you limiting this to
> internal APIs within Tempest/Devstack that projects can use for
> testing/deployment, or are you referring to things like the nova-compute
> service which has an internal RPC API?

Any APIs that are used by other projects. So, an RPC API will probably
be out of scope.

> I feel like I'm missing some context when reading this email because
> there are a lot of references to plugins with no clear definition, that
> I can see, of what exactly you mean by that.

It is for any project that has cross project code. If a project has
ways for other projects to hook in, this interface should be the same.

This means that a project cannot say the Nova can have code that calls
internal code but Glance has to use a plugin that only has access to
certain calls.

>>
>> 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.
>
> Can you provide more clarity on how "openstack dns quota set --foo bar"
> differs from setting a quota on Nova/Neutron/Cinder?

Sure - nearly all other quotas are set either in the "admin" -> "quotas" 
panel in Horizon (which plugins cannot add their quotas
there.

For the cli - quotas are set as `openstack quota set --instances 10`

I realise it is a small difference, but each of these makes it more
complex for end users, and means that Designate had to re-invent the
quotas command, and keep it in their plugin.

>>
>> 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.
>
> Has there been an attempt to elevate these internal interfaces into
> stable and publicly consumable interfaces? Was there resistance to such
> an effort?

When we have asked previously, we have been told that certain parts
of tempest "are not really meant for plugins".

The main part that is used that is not part of the tempest stable
interface is the base test class.

This is the bit that sets up credentials, clients, and other useful
things.

There is a base test class in the tempest lib - but it is very sparse -
meaning any project using it would have to re-invent creating users,
resources, and clients.

https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
vs
https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22

>>
>> 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.
>
> Is this just a matter of nobody is doing this work, or are there claims
> that some projects are special and should have access that other
> projects do not?

There is claims that some projects are special, and should have more
access.

>>
>> 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
>
> __________________________________________________________________________
> 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
>