Open Stack

On 07/17/2016 11:04 PM, Jay Pipes wrote:
> 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.

Not entirely related example, but still in support of the original point 
(IMO): grenade currently does not catch smoke tests coming from tempest 
plugins when running after upgrade. It's just one missing call [1], and 
it probably would not go unnoticed if Nova tests did not run ;)

[1] https://review.openstack.org/337372

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