On 12 Feb 2017, at 12:13, Boris Bobrov <bbob...@mirantis.com<mailto:bbob...@mirantis.com>> wrote:
I would like to talk about it too. On 02/10/2017 11:56 PM, Matt Riedemann wrote: Operators want hierarchical quotas [1]. Nova doesn't have them yet and we've been hesitant to invest scarce developer resources in them since we've heard that the implementation for hierarchical quotas in Cinder has some issues. But it's unclear to some (at least me) what those issues are. I don't know what the actual issue is, but from from keystone POV the issue is that it basically replicates project tree that is stored in keystone. On top of usual replication issues, there is another one -- it requires too many permissions. Basically, it requires service user to be cloud admin. I have not closely followed the cinder implementation since the CERN and BARC Mumbai focus has more around Nova. The various feedbacks I have had was regarding how to handle overcommit on the cinder proposal. A significant share of the operator community would like to allow - No overcommit for the ‘top level’ project (i.e. you can’t use more than you are allocated)] - Sub project over commit is OK (i.e. promising your sub projects more is OK, sum of the commitment to subprojects>project is OK but should be given an error if it actually happens) Has anyone already planned on talking about hierarchical quotas at the PTG, like the architecture work group? I know there was a bunch of razzle dazzle before the Austin summit about quotas, but I have no idea what any of that led to. Is there still a group working on that and can provide some guidance here? In my opinion, projects should not re-implements quotas every time. I would like to have a common library for enforcing quotas (usages) and a service for storing quotas (limits). We should also think of a way to transfer necessary projects subtree from keystone to quota enforcer. We could store quota limits in keystone and distribute it in token body, for example. Here is a POC that we did some time ago -- https://review.openstack.org/#/c/403588/ and https://review.openstack.org/#/c/391072/ But it still has the issue with permissions. There has been an extended discussion since the Boson proposal at the Hong Kong summit on how to handle quotas, where a full quota service was proposed. A number of ideas have emerged since then - Quota limits stored in Keystone with the project data - An oslo library to support checking that a resource request would be OK One Forum session at the summit is due to be on this topic. Some of the academic use cases are described in https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html but commercial reseller models are valid here where - company A has valuable resources to re-sell (e.g. flood risk and associated models) - company B signs an agreement with Company A (e.g. an insurance company wants to use flood risk data as factor in their cost models) The natural way of delivering this is that ‘A’ gives a pricing model based on ‘B’’s consumption of compute and storage resources. Tim [1] http://lists.openstack.org/pipermail/openstack-operators/2017-January/012450.html __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
