Hi Sundar,

Could you test this from a different host instead of performing this test from localhost.

Best Regards,
Vijay Kumar

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Sundaresan Rajangam
Sent: Monday, August 14, 2017 11:11 PM
To: Vijay Kumar Shankaran <email address hidden>
Subject: Re: [Bug 1701426] Incorrect response from analytics api server when queried for number of VMIs greater than 48K

Hi Vivek,

What do you mean by you got different data?
Do you have the o/p from both the queries?

I tried few times. I got the same number of VMI UVEs:

root@5b7s1-4-vm2:~# curl -u <> localhost:8181/analytics/uves/virtual-machine-interfaces | python -m json.tool | grep href | wc -lc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6541k  100 6541k    0     0  2899k      0  0:00:02  0:00:02 --:--:-- 2898k
  30911 4616562
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~# curl -u <> localhost:8181/analytics/uves/virtual-machine-interfaces | python -m json.tool | grep href | wc -lc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6541k  100 6541k    0     0  2774k      0  0:00:02  0:00:02 --:--:-- 2775k
  30911 4616562
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~# curl -u <> localhost:8181/analytics/uves/virtual-machine-interfaces | python -m json.tool | grep href | wc -lc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6541k  100 6541k    0     0  2835k      0  0:00:02  0:00:02 --:--:-- 2835k
  30911 4616562
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~# curl -u <> localhost:8181/analytics/uves/virtual-machine-interfaces | python -m json.tool | grep href | wc -lc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6541k  100 6541k    0     0  3048k      0  0:00:02  0:00:02 --:--:-- 3049k
  30911 4616562
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~#
root@5b7s1-4-vm2:~# curl -u <> localhost:8181/analytics/uves/virtual-machine-interfaces | python -m json.tool | grep href | wc -lc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6541k  100 6541k    0     0  2811k      0  0:00:02  0:00:02 --:--:— 2811k
  30911 4616562

Thanks,
Sundar


> On Aug 13, 2017, at 9:59 AM, vivekananda shenoy <email address hidden> wrote:
> 
> Hi Sundar,
> 
> QA team scale setup is available with the 3.1 code. This setup as 64K 
> VMIs. I tried querying the UVE's and I see that the 2 times I did the 
> queries returned different data. Both times got a 200 OK. But then it 
> is possible that the O/P data has the same UVE's but they are in 
> different order each time we query the UVE's.
> 
> However the setup is available and you may have a better way to figure 
> this out. Also can you provide an tentative ETA for this issue as NTTC 
> is constantly asking us the same ?
> 
> IP : 10.87.121.77
> root/contrail123
> 
> Regards,
> Vivek
> 
> 
> ====================
> 
> root@5b7s1-1-vm1:~# source /etc/contrail/openstackrc 
> root@5b7s1-1-vm1:~# root@5b7s1-1-vm1:~# root@5b7s1-1-vm1:~# keystone 
> token-get
> /usr/lib/python2.7/dist-packages/keystoneclient/shell.py:64: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient.
>  'python-keystoneclient.', DeprecationWarning)
> /usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py:145: DeprecationWarning: Constructing an instance of the keystoneclient.v2_0.client.Client class without a session is deprecated as of the 1.7.0 release and may be removed in the 2.0.0 release.
>  'the 2.0.0 release.', DeprecationWarning)
> /usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py:147: 
> DeprecationWarning: Using the 'tenant_name' argument is deprecated in 
> version '1.7.0' and will be removed in version '2.0.0', please use the 
> 'project_name' argument instead  super(Client, 
> self).__init__(**kwargs)
> /usr/lib/python2.7/dist-packages/debtcollector/renames.py:45: 
> DeprecationWarning: Using the 'tenant_id' argument is deprecated in 
> version '1.7.0' and will be removed in version '2.0.0', please use the 
> 'project_id' argument instead  return f(*args, **kwargs)
> /usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py:371: DeprecationWarning: Constructing an HTTPClient instance without using a session is deprecated as of the 1.7.0 release and may be removed in the 2.0.0 release.
>  'the 2.0.0 release.', DeprecationWarning)
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:140: DeprecationWarning: keystoneclient.session.Session is deprecated as of the 2.1.0 release in favor of keystoneauth1.session.Session. It will be removed in future releases.
>  DeprecationWarning)
> /usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/base.py:56: DeprecationWarning: keystoneclient auth plugins are deprecated as of the 2.1.0 release in favor of keystoneauth1 plugins. They will be removed in future releases.
>  'in future releases.', DeprecationWarning)
> +-----------+----------------------------------+
> |  Property |              Value               |
> +-----------+----------------------------------+
> |  expires  |       2017-08-13T17:52:21Z       |
> |     id    | 0610d02e9d964e3f942c96955dd6b88d |
> | tenant_id | 715019844b9d4912b15bd8385bf484dd |  user_id  | 
> | 8497548cca3845829c2fbe4bf4821fad |
> +-----------+----------------------------------+
> root@5b7s1-1-vm1:~#
> root@5b7s1-1-vm1:~#
> root@5b7s1-1-vm1:~# export token="0610d02e9d964e3f942c96955dd6b88d"
> root@5b7s1-1-vm1:~#
> root@5b7s1-1-vm1:~#
> root@5b7s1-1-vm1:~# curl -H "X-Auth-token:$token" http://localhost:8081/analytics/uves/virtual-machine-interface/default-domain:*:*?flat > op1.txt
>  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                 Dload  Upload   Total   Spent    Left  Speed
> 100 17.3M    0 17.3M    0     0   326k      0 --:--:--  0:00:54 --:--:--  348k
> root@5b7s1-1-vm1:~#
> root@5b7s1-1-vm1:~# curl -H "X-Auth-token:$token" http://localhost:8081/analytics/uves/virtual-machine-interface/default-domain:*:*?flat > op2.txt
>  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                 Dload  Upload   Total   Spent    Left  Speed
> 100 17.3M    0 17.3M    0     0   436k      0 --:--:--  0:00:40 --:--:--  393k
> root@5b7s1-1-vm1:~#
> root@5b7s1-1-vm1:~# md5sum op1.txt op2.txt
> 1deb6ecc806431fee99c30d57bdec911  op1.txt
> 5c6fc78789ee5542884fe09e3eb6a909  op2.txt root@5b7s1-1-vm1:~# 
> root@5b7s1-1-vm1:~#
> 
> --
> You received this bug notification because you are a member of 
> Contrail Systems engineering, which is subscribed to Juniper Openstack.
> https://bugs.launchpad.net/bugs/1701426
> 
> Title:
>  Incorrect response from analytics api server when queried for number  
> of VMIs greater than 48K
> 
> Status in Juniper Openstack:
>  In Progress
> Status in Juniper Openstack r3.1 series:
>  In Progress
> Status in Juniper Openstack r3.2 series:
>  In Progress
> Status in Juniper Openstack r4.0 series:
>  In Progress
> Status in Juniper Openstack trunk series:
>  In Progress
> 
> Bug description:
>  Customer is running a Curl against analytics api for the number of Virtual Machine interface.
>  When the number of VMI interface is less than 48K the response from the Analytics server matches with that of VMI on the setup. However, when there are large number of VMI >48K the response doesn’t match with the existing with VMI and we get different response each time. We get a http 200 OK response in both the case.
>  Following response matches with the existing VMI  Analytics API / 
> configAPI
>  11 k VMI: 11135/11135 OK GET 200 5886 759 12.00 3 60 4
>  30 k VMI: 30000/30000 OK GET 200 15904063 35.785529
>  36 k VMI: 36000/36000 OK GET 200 19084807 45.094492
>  44.3 k VMI: 44327/44327 OK GET 200 23434148 59.721491
>  45 k VMI: 45000/45000 OK GET 200 23826101 62.304583
> 
> 
>  The ones that doesn’t match are
>  46.8 k VMI: 46060/46800 NG GET 200 24316603 59.041701
>  60 k VMI: 55704/60000 NG GET 200 29530343 97.429255
>  177 k VMI: 159975/177061 NG GET 200 84574245 323.764904
> 
>  Customer is on v3.1.3 Build 75 and the curl command executed is  curl 
> http://localhost:8081/analytics/uves/virtual-machine-interface/default
> -domain:*:*?flat
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juniperopenstack/+bug/1701426/+subscription
> s

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1701426

Title:
  Incorrect response from analytics api server when queried for number
  of VMIs greater than 48K

Status in Juniper Openstack:
  In Progress
Status in Juniper Openstack r3.1 series:
  In Progress
Status in Juniper Openstack r3.2 series:
  In Progress
Status in Juniper Openstack r4.0 series:
  In Progress
Status in Juniper Openstack trunk series:
  In Progress

Bug description:
  Customer is running a Curl against analytics api for the number of Virtual Machine interface.
  When the number of VMI interface is less than 48K the response from the Analytics server matches with that of VMI on the setup. However, when there are large number of VMI >48K the response doesn’t match with the existing with VMI and we get different response each time. We get a http 200 OK response in both the case.
  Following response matches with the existing VMI
  Analytics API / configAPI
  11 k VMI: 11135/11135 OK GET 200 5886 759 12.00 3 60 4
  30 k VMI: 30000/30000 OK GET 200 15904063 35.785529
  36 k VMI: 36000/36000 OK GET 200 19084807 45.094492
  44.3 k VMI: 44327/44327 OK GET 200 23434148 59.721491
  45 k VMI: 45000/45000 OK GET 200 23826101 62.304583

  
  The ones that doesn’t match are
  46.8 k VMI: 46060/46800 NG GET 200 24316603 59.041701
  60 k VMI: 55704/60000 NG GET 200 29530343 97.429255
  177 k VMI: 159975/177061 NG GET 200 84574245 323.764904

  Customer is on v3.1.3 Build 75 and the curl command executed is
  curl http://localhost:8081/analytics/uves/virtual-machine-interface/default-domain:*:*?flat

To manage notifications about this bug go to:
https://bugs.launchpad.net/juniperopenstack/+bug/1701426/+subscriptions