Open Stack

On 07/14/2016 12:21 PM, Hayes, Graham wrote:
> 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.

There *is* no 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.

This has nothing to do with the big tent and everything to do with the 
fact that the community at large has conflated quotas -- i.e. the limit 
of a particular class of resource that a user or tenant can consume -- 
with the usage of a particular class of resource. The two things are not 
the same nor do they need to be handled by the same service, IMHO.

I've proposed before that quotas -- i.e. the *limits* for different 
resource classes that a consumer of those resources has -- be handled by 
the Keystone API. This is the endpoint that I personally think makes the 
most sense to house this information.

Usage information is necessarily the domain of the individual service 
projects who must control allocation/consumption of resources under 
their control. It would be *helpful* to have a set of best-practice 
guidelines for projects to follow in safely accounting for consumption 
of resources, but "the big tent" has nothing to do with our community 
failing to do this. We've failed to do this from the beginning of 
OpenStack, well before the big tent was just a spark in the minds of the TC.

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

What "resources" are you referring to above? What is the "unstable 
interface" you are referring to? Tempest should only ever be validating 
public REST APIs.

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

An example here would be super-useful, since as mentioned above, Tempest 
should only be validating public HTTP/REST APIs.

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

I guess I don't understand what you are referring to as a "plugin" 
above. Are you referring to devstack libXXX things? Or are you referring 
to *drivers* for things like the hypervisor in Nova or the ML2 mech 
drivers in Neutron? Or something else entirely?

Best,
-jay