Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone
Hi, I also feel that quota as a service is the best approach.It is justified as well, since we have multiple projects(Nova,Cinder,Neutron) now ,having the concept of quotas.Keeping it under a single umbrella, paves the way for lesser code duplication and easier feature enhancement like adoption of hierarchical quotas, and also better code management. best regards, sajeesh From: Andrey Volkov [avol...@mirantis.com] Sent: 14 December 2016 17:00:32 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone Hi, I think one of the issues we're trying to solve here is duplication reducing. Quotas in OpenStack commonly contain two parts: limits management and limits enforcement. If we're talking about library (delimiter) vs service (keystone or quota service) for a duplication reducing in a limits management then IMO service is more appropriate way because: - Now we have API endpoint for limits management for the end user and we will need it in the future. Library can reduce an amount of code for such endpoint but can't totally eliminate it. - Besides the code in services, we have api-ref, docs, and clients also and library can't reduce an effort for supporting those. - Centralized limits management service can provide fresh and consistent API (see quota_class, quota_sets). If we're talking about limits enforcement then it's more subtle thing. I really agree with Jay that problem can be related to the cache for usages. And I don't see the way how we can skip saving into reservation table because we can easily define a moment of reservation with reservation table but it can be hard with "real" objects like instance as they have its own logic of creating. I think a library can be appropriate if services like nova or cinder have a possibility to deeply integrate external libraries (like django apps). I mean if a library has own DB tables, cli commands, etc. it can be seamlessly integrated to the main app. I'm not sure it's the case for nova, for example. Therefore, for me, separate service is the winner here too. Sajeesh Cimson Sasi writes: > Hi, > There was an ongoing project of delimiter for Cross Project Quota > Management. > But I don't know the current status. > Kindly have a look at it. > https://review.openstack.org/#/c/284454/ > More discussions are required on this.As more and more projects or > services are having the concept ofquotas,Quota as a service can also be > thought of.Anyway more discussions are required on this topic. >best regards, > sajeesh > > From: Jay Pipes [jaypi...@gmail.com] > Sent: 13 December 2016 18:55:14 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and > limits in the Keystone > > On 12/13/2016 08:09 AM, Kseniya Tychkova wrote: >> Hi, >> I would like to share a spec [1] with you. >> The main idea of this spec is to start a discussion about quota >> management in the OpenStack. >> >> Quotas are scattered across OpenStack services. Each service defines >> it's own model and API for >> managing resource's limits. Because of that, there are several problems: >> >> * Names of the resources and resource-service mapping are hardcoded. >> They are hardcoded in the service code (Nova, for example) and it >> should be hardcoded in the client code (Horizon, for example). >> >> * There is no centralized quota management for OpenStack projects. >> * Cinder, Nova and Neutron support (or going to support) hierarchical >> quotas in different ways. >> >> There should be a single point of managing quotas in OpenStack. >> Keystone looks like a proper place to store resource's limits because: >> >> * Keystone stores projects >> * Limits are belong to project. > > Another excellent reason to store quota limits in Keystone is because > virtually all non-list operations require some interaction with quota > limits, and requiring Nova (or Cinder or Neutron) to call out to yet > another service each time the user makes one of those non-list > operations is sub-optimal when Nova is already making a call to Keystone > for authentication. > > The alternative is to have a separate REST API service just for storing > and returning the quota limits and have Nova, Cinder and Neutron call > this new service each time a non-list operation is made. While this is > possible, it's just yet another service that needs to be managed and > deployed by all installations of OpenStack. > > Best, > -jay > >> There are a lot of
Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone
Hi, I think one of the issues we're trying to solve here is duplication reducing. Quotas in OpenStack commonly contain two parts: limits management and limits enforcement. If we're talking about library (delimiter) vs service (keystone or quota service) for a duplication reducing in a limits management then IMO service is more appropriate way because: - Now we have API endpoint for limits management for the end user and we will need it in the future. Library can reduce an amount of code for such endpoint but can't totally eliminate it. - Besides the code in services, we have api-ref, docs, and clients also and library can't reduce an effort for supporting those. - Centralized limits management service can provide fresh and consistent API (see quota_class, quota_sets). If we're talking about limits enforcement then it's more subtle thing. I really agree with Jay that problem can be related to the cache for usages. And I don't see the way how we can skip saving into reservation table because we can easily define a moment of reservation with reservation table but it can be hard with "real" objects like instance as they have its own logic of creating. I think a library can be appropriate if services like nova or cinder have a possibility to deeply integrate external libraries (like django apps). I mean if a library has own DB tables, cli commands, etc. it can be seamlessly integrated to the main app. I'm not sure it's the case for nova, for example. Therefore, for me, separate service is the winner here too. Sajeesh Cimson Sasi writes: > Hi, > There was an ongoing project of delimiter for Cross Project Quota > Management. > But I don't know the current status. > Kindly have a look at it. > https://review.openstack.org/#/c/284454/ > More discussions are required on this.As more and more projects or > services are having the concept ofquotas,Quota as a service can also be > thought of.Anyway more discussions are required on this topic. >best regards, > sajeesh > > From: Jay Pipes [jaypi...@gmail.com] > Sent: 13 December 2016 18:55:14 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and > limits in the Keystone > > On 12/13/2016 08:09 AM, Kseniya Tychkova wrote: >> Hi, >> I would like to share a spec [1] with you. >> The main idea of this spec is to start a discussion about quota >> management in the OpenStack. >> >> Quotas are scattered across OpenStack services. Each service defines >> it's own model and API for >> managing resource's limits. Because of that, there are several problems: >> >> * Names of the resources and resource-service mapping are hardcoded. >> They are hardcoded in the service code (Nova, for example) and it >> should be hardcoded in the client code (Horizon, for example). >> >> * There is no centralized quota management for OpenStack projects. >> * Cinder, Nova and Neutron support (or going to support) hierarchical >> quotas in different ways. >> >> There should be a single point of managing quotas in OpenStack. >> Keystone looks like a proper place to store resource's limits because: >> >> * Keystone stores projects >> * Limits are belong to project. > > Another excellent reason to store quota limits in Keystone is because > virtually all non-list operations require some interaction with quota > limits, and requiring Nova (or Cinder or Neutron) to call out to yet > another service each time the user makes one of those non-list > operations is sub-optimal when Nova is already making a call to Keystone > for authentication. > > The alternative is to have a separate REST API service just for storing > and returning the quota limits and have Nova, Cinder and Neutron call > this new service each time a non-list operation is made. While this is > possible, it's just yet another service that needs to be managed and > deployed by all installations of OpenStack. > > Best, > -jay > >> There are a lot of possible issues with “store limits in Keystone” >> approach. But all of them can be discussed >> and such discussion should lead to the good solution for quotas >> management in Openstack. >> >> Please take a look at the spec when you have time and share your ideas >> or concerns. >> >> [1] https://review.openstack.org/#/c/363765/ >> >> >> Kind regards, >> Kseniya >> >> >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: opensta
Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone
On 12/13/2016 11:27 AM, Sajeesh Cimson Sasi wrote: Hi, There was an ongoing project of delimiter for Cross Project Quota Management. But I don't know the current status. Kindly have a look at it. https://review.openstack.org/#/c/284454/ More discussions are required on this.As more and more projects or services are having the concept ofquotas,Quota as a service can also be thought of.Anyway more discussions are required on this topic. I raised objections to having a separate endpoint process quota *usages* when the Delimiter project was proposed: http://openstack.markmail.org/message/7ixvezcsj3uyiro6 I stand by those objections for the reasons stated in the above ML thread. Best, -jay __ 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
Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone
Hi, There was an ongoing project of delimiter for Cross Project Quota Management. But I don't know the current status. Kindly have a look at it. https://review.openstack.org/#/c/284454/ More discussions are required on this.As more and more projects or services are having the concept ofquotas,Quota as a service can also be thought of.Anyway more discussions are required on this topic. best regards, sajeesh From: Jay Pipes [jaypi...@gmail.com] Sent: 13 December 2016 18:55:14 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone On 12/13/2016 08:09 AM, Kseniya Tychkova wrote: > Hi, > I would like to share a spec [1] with you. > The main idea of this spec is to start a discussion about quota > management in the OpenStack. > > Quotas are scattered across OpenStack services. Each service defines > it's own model and API for > managing resource's limits. Because of that, there are several problems: > > * Names of the resources and resource-service mapping are hardcoded. > They are hardcoded in the service code (Nova, for example) and it > should be hardcoded in the client code (Horizon, for example). > > * There is no centralized quota management for OpenStack projects. > * Cinder, Nova and Neutron support (or going to support) hierarchical > quotas in different ways. > > There should be a single point of managing quotas in OpenStack. > Keystone looks like a proper place to store resource's limits because: > > * Keystone stores projects > * Limits are belong to project. Another excellent reason to store quota limits in Keystone is because virtually all non-list operations require some interaction with quota limits, and requiring Nova (or Cinder or Neutron) to call out to yet another service each time the user makes one of those non-list operations is sub-optimal when Nova is already making a call to Keystone for authentication. The alternative is to have a separate REST API service just for storing and returning the quota limits and have Nova, Cinder and Neutron call this new service each time a non-list operation is made. While this is possible, it's just yet another service that needs to be managed and deployed by all installations of OpenStack. Best, -jay > There are a lot of possible issues with “store limits in Keystone” > approach. But all of them can be discussed > and such discussion should lead to the good solution for quotas > management in Openstack. > > Please take a look at the spec when you have time and share your ideas > or concerns. > > [1] https://review.openstack.org/#/c/363765/ > > > Kind regards, > Kseniya > > > > > > > __ > 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 > __ 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 __ 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
Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone
On 12/13/2016 08:09 AM, Kseniya Tychkova wrote: Hi, I would like to share a spec [1] with you. The main idea of this spec is to start a discussion about quota management in the OpenStack. Quotas are scattered across OpenStack services. Each service defines it's own model and API for managing resource's limits. Because of that, there are several problems: * Names of the resources and resource-service mapping are hardcoded. They are hardcoded in the service code (Nova, for example) and it should be hardcoded in the client code (Horizon, for example). * There is no centralized quota management for OpenStack projects. * Cinder, Nova and Neutron support (or going to support) hierarchical quotas in different ways. There should be a single point of managing quotas in OpenStack. Keystone looks like a proper place to store resource's limits because: * Keystone stores projects * Limits are belong to project. Another excellent reason to store quota limits in Keystone is because virtually all non-list operations require some interaction with quota limits, and requiring Nova (or Cinder or Neutron) to call out to yet another service each time the user makes one of those non-list operations is sub-optimal when Nova is already making a call to Keystone for authentication. The alternative is to have a separate REST API service just for storing and returning the quota limits and have Nova, Cinder and Neutron call this new service each time a non-list operation is made. While this is possible, it's just yet another service that needs to be managed and deployed by all installations of OpenStack. Best, -jay There are a lot of possible issues with “store limits in Keystone” approach. But all of them can be discussed and such discussion should lead to the good solution for quotas management in Openstack. Please take a look at the spec when you have time and share your ideas or concerns. [1] https://review.openstack.org/#/c/363765/ Kind regards, Kseniya __ 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 __ 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
[openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone
Hi, I would like to share a spec [1] with you. The main idea of this spec is to start a discussion about quota management in the OpenStack. Quotas are scattered across OpenStack services. Each service defines it's own model and API for managing resource's limits. Because of that, there are several problems: - Names of the resources and resource-service mapping are hardcoded. They are hardcoded in the service code (Nova, for example) and it should be hardcoded in the client code (Horizon, for example). - There is no centralized quota management for OpenStack projects. - Cinder, Nova and Neutron support (or going to support) hierarchical quotas in different ways. There should be a single point of managing quotas in OpenStack. Keystone looks like a proper place to store resource's limits because: - Keystone stores projects - Limits are belong to project. There are a lot of possible issues with “store limits in Keystone” approach. But all of them can be discussed and such discussion should lead to the good solution for quotas management in Openstack. Please take a look at the spec when you have time and share your ideas or concerns. [1] https://review.openstack.org/#/c/363765/ Kind regards, Kseniya __ 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
