Seems there is a bug in addon-pyone or xml API

Hello! Seems there is a bug in addon-pyone or xml API
I created user with 40 GB of storage disk space quote, then i created 3 vm’s with 10GB disks for each,
reduced user quota to 20GB, ran script and got error

pyone.OneAuthorizationException: [one.vm.allocate] User [141] : user [141] limit of 20480 reached for SIZE quota in DATASTORE with ID: 102.

but have one more vm in vm quota

script:

import pyone
user = ""
password = ""

one = pyone.OneServer("https://:2633/RPC2", session="{}:{}".format(user,password))

VM = {'TEMPLATE': {'CONTEXT': {'NETWORK': u'YES',
   'SSH_PUBLIC_KEY': u'$USER[SSH_PUBLIC_KEY]'},
  'CPU': u'2',
  'DISK': {'DEV_PREFIX': u'vd',
   'IMAGE': u',
   'IMAGE_UNAME': u'',
   'SIZE': u'10240'},
  'MEMORY': u'2048',
  'NAME': u'cdd847468ae4.debug.local',
  'NIC': {'NETWORK': u'', 'NETWORK_UNAME': u"'},
  'VCPU': u'2'}}

one.vm.allocate(VM)


Versions of the related components and OS (frontend, hypervisors, VMs): opennebula-server-5.4.6-1.x86_64, opennebula-sunstone-5.4.6-1.x86_64,
qemu-kvm-common-1.5.3-156.el7_5.5.x86_64
opennebula-node-kvm-5.4.6-1.x86_64
qemu-kvm-1.5.3-156.el7_5.5.x86_64
CentOS Linux release 7.5.1804 (Core)

Hi!

I don’t think PyONE is that smart. looks like the reject comes from the server.

seems to believe that the user is not authorized due to quotas when allocating the new VM.

Sorry, what I mean is that possibly the same operation via Sustone or CLI will come back with the same error.

yep, i can create vm from Sunstone in cloud view with overquoted user disk space without any error

and with the CLI?
PyONE uses the XMLRPC interface, and so does the CLI
The module just forwards whatever the server replies.
but I have to admit that seems very strange to me too.

here is cli output

onevm create one_test_quota.one --user test_user --password password
[one.vm.allocate] User [141] : user [141] limit of 20480 reached for SIZE quota in DATASTORE with ID: 102

but in user vm quota +1

I have user with 11 running vm’s

oneuser show 141

RESOURCE USAGE & QUOTAS

    NUMBER OF VMS               MEMORY                  CPU     SYSTEM_DISK_SIZE
     **11** /      14     12.5G /        -     15.00 /        -        0M /        -

I’m trying to create another one

onevm create one_test_quota.one --user test_user --password password
[one.vm.allocate] User [141] : user [141] limit of 20480 reached for SIZE quota in DATASTORE with ID: 102

I got an error, but the quota changes, and now i have 12 running vm’s in quota

oneuser show 141
RESOURCE USAGE & QUOTAS

    NUMBER OF VMS               MEMORY                  CPU     SYSTEM_DISK_SIZE
     **12** /      14     12.5G /        -     15.00 /        -        0M /        -

I am not sure what the expected behavior is, I am not familiar with quotas.

The CLI and Pyone should be equivalent.

Pyone is “dumb”, in the sense that translates your method calls to XMLRPC calls, and then uses the XSDs to convert XML reply into an object. In the process if an error is detected, it just throws an exception with its content/type.

can you point me to more information about overquoting?

how do you think pyone should behave in this case?

Thanks to you, I realized that the problem is not in the pyone, since it is reproduced via cli
It looks like a problem in the XML RPC API

Hi,

If the VM cannot be created because of limit reach, the number of “running” VM must not increase.
I am not sure the issue is on XML RPC as the number of running VM is not correct.
Is the showback / accounting saying that the VM is also running or not ?

This vm’s don’t showing as running vm’s, they showing only in user quota

Hello,

My bad about using “running”. Can you connect to the DB directly and check what are the values stored for the quota and for the number of VM for this user.
Maybe there is a kind of race condition during quota check / update.
Do you also have different quota for the user and for the group ?

Hello,

select * from user_quotas where user_oid like 141;
<VMS_USED><![CDATA[12]]></VMS_USED>
mysql> select count(*) from vm_pool where uid like 141;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

no, the group does not have any quotas at all

Also, onedb fsck successfully fix all qouta related inconsistencies

So the correct number was 6 instead of 12.
You fixed this number when you ran onedb fsck.

It looks like there is something wrong between XML RPC and DB indeed.