[openstack-dev] [tc][all] Plugins for all

Sean Dague sean at dague.net
Wed Jul 20 23:45:05 UTC 2016


On 07/18/2016 06:49 AM, Dmitry Tantsur wrote:
> 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

The patch is merged.

Also... missing tests have gone missing for long times on all kinds of 
projects, including nova / neutron. Missing tests require people keeping 
an eye on things, because they don't fail when they disappear.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list