Open Stack

On 17/07/2016 22:08, 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.

Well if you are nova, neutron or cinder there is.

http://docs.openstack.org/admin-guide/cli_set_quotas.html
http://docs.openstack.org/admin-guide/dashboard_set_quotas.html


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

As have I, but the reality is that *currently* limits are set by quotas.

(As a side note, keystone is the only place that this makes any sense,
but we needed quotas a few years ago, and we had to do what everyone
else had done at the time)

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

The resources in tempest - thinks like setting up users / projects for
running the tests, cleaning up resources post testing, checking if
services are enabled / disabled in the cloud being tested, tagging tests
(smoke, slow, etc)

The are all used by projects using tempest for testing, and all of the
above are only available to projects not using the plugin interface
(the in tree tempest tests, in the openstack/tempest repository)

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