On 25 September 2013 18:15, Phil Day <email address hidden> wrote:
> To reproduce in DevStack:
>
> i) Set the default cores quota to -1 (unlimited). i.e add
> "quota_cores=-1" to nova.conf
> ii) Restart the Nova API server
> iii) Request a number of instances that spans the allowed quota of
> instances (default 10)
>
> ubuntu@list-all:/mnt/devstack$ nova list
> +----+------+--------+------------+-------------+----------+
> | ID | Name | Status | Task State | Power State | Networks |
> +----+------+--------+------------+-------------+----------+
> +----+------+--------+------------+-------------+----------+
>
> ubuntu@list-all:/mnt/devstack$ nova boot --image
> cd4e2b6c-8df9-4f31-a553-b83082dc6977 --num-instances 12 --flavor 1 philx
> ERROR: Quota exceeded for instances: Requested 1-12, but already used 0 of
> 10 instances (HTTP 413) (Request-ID:
> req-42d0f729-c360-452b-b92f-ff02e673e9d4)
>
> The issue seems to be that the code in compute/api.py
> _check_num_instances_quota() when it detects an over quota request
> doesn't correctly handle "-1" values for quotas.
>
> By contrast the code in quota.py limit_check has specific checks for
> quota values to be >=0 when making checks.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1224453
>
> Title:
> min_count ignored for instance create
>
> Status in OpenStack Compute (Nova):
> Incomplete
>
> Bug description:
> The server create API takes min_count and max_count values for the
> number of instances to be created, where the actual number to be
> created should be the highest value allowed by quota between these
> limits.
>
> However the code in compute/api.py does a single check against
> max_count and then treats the exeception as a failure - resulting in
> messages such as:
>
> min_count=1
> max_count= (quota+1)
>
> "Quota exceeded for instances: Requested 1, but already used 13 of 40
> instances"
>
>
> The code in _check_num_instances_quota() looks like it has most of the
> logic for adjusting the values when it gets an OverQuota exception
> from the initial reservation request based on max_count - but always
> ends up raising TooManyInstances .
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1224453/+subscriptions
>
Cool I got a bug to fix!
Thanks Phil, I'll have a look.
On 25 September 2013 18:15, Phil Day <email address hidden> wrote:
> To reproduce in DevStack: list-all: /mnt/devstack$ nova list -----+- ------- +------ ------+ ------- ------+ ------- ---+ -----+- ------- +------ ------+ ------- ------+ ------- ---+ -----+- ------- +------ ------+ ------- ------+ ------- ---+ list-all: /mnt/devstack$ nova boot --image 8df9-4f31- a553-b83082dc69 77 --num-instances 12 --flavor 1 philx c360-452b- b92f-ff02e673e9 d4) num_instances_ quota() when it detects an over quota request /bugs.launchpad .net/bugs/ 1224453 num_instances_ quota() looks like it has most of the /bugs.launchpad .net/nova/ +bug/1224453/ +subscriptions
>
> i) Set the default cores quota to -1 (unlimited). i.e add
> "quota_cores=-1" to nova.conf
> ii) Restart the Nova API server
> iii) Request a number of instances that spans the allowed quota of
> instances (default 10)
>
> ubuntu@
> +----+-
> | ID | Name | Status | Task State | Power State | Networks |
> +----+-
> +----+-
>
> ubuntu@
> cd4e2b6c-
> ERROR: Quota exceeded for instances: Requested 1-12, but already used 0 of
> 10 instances (HTTP 413) (Request-ID:
> req-42d0f729-
>
> The issue seems to be that the code in compute/api.py
> _check_
> doesn't correctly handle "-1" values for quotas.
>
> By contrast the code in quota.py limit_check has specific checks for
> quota values to be >=0 when making checks.
>
> --
> You received this bug notification because you are a bug assignee.
> https:/
>
> Title:
> min_count ignored for instance create
>
> Status in OpenStack Compute (Nova):
> Incomplete
>
> Bug description:
> The server create API takes min_count and max_count values for the
> number of instances to be created, where the actual number to be
> created should be the highest value allowed by quota between these
> limits.
>
> However the code in compute/api.py does a single check against
> max_count and then treats the exeception as a failure - resulting in
> messages such as:
>
> min_count=1
> max_count= (quota+1)
>
> "Quota exceeded for instances: Requested 1, but already used 13 of 40
> instances"
>
>
> The code in _check_
> logic for adjusting the values when it gets an OverQuota exception
> from the initial reservation request based on max_count - but always
> ends up raising TooManyInstances .
>
> To manage notifications about this bug go to:
> https:/
>