Ajay,

Seems like you are using old rally.
Because it should show detailed information about error.
Recently we merged this: https://review.openstack.org/#/c/118169/ that
shows full information.


Could you send the set of commands that you run to apply neutron context?


Best regards,
Boris Pavlovic


On Sun, Sep 7, 2014 at 10:57 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:

> Massoom,
>
> Seems like you are using old rally code.
>
>
> On Sun, Sep 7, 2014 at 10:33 PM, Ajay Kalambur (akalambu) <
> akala...@cisco.com> wrote:
>
>>  The following context worked for me.
>>
>>
>>              "context": {
>>                 "neutron_network": {
>>                     "network_cidr": "10.%s.0.0/16",
>>                 },
>>                 "users": {
>>                     "tenants": 1,
>>                     "users_per_tenant": 2
>>                 }
>>             }
>>
>>
>>
>>   From: masoom alam <masoom.a...@gmail.com>
>> Date: Sunday, September 7, 2014 at 5:27 AM
>> To: akalambu <akala...@cisco.com>
>> Cc: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [rally][iperf] Benchmarking network
>> performance
>>
>>   The problem lies in this patch:
>>
>>  https://review.openstack.org/#/c/96300
>>
>>  Even If I apply it, i get an error that Unknown Neutron context. The
>> patch is correctly applied - some 20 times :)
>>
>>  Task and output is as follows:
>>
>>
>>  {
>>
>>     "VMTasks.boot_runcommand_delete": [
>>
>>         {
>>
>>             "args": {
>>
>>                 "flavor": {
>>
>>                     "name": "m1.tiny"
>>
>>                 },
>>
>>                 "image": {
>>
>>                     "name": "cirros-0.3.2-x86_64-uec"
>>
>>                 },
>>
>>                 "fixed_network": "net04",
>>
>>                 "floating_network": "net04_ext",
>>
>>                 "use_floatingip": true,
>>
>>                 "script":
>> "/home/alam/Desktop/rally/doc/samples/tasks/support/instance_dd_test.sh",
>>
>>                 "interpreter": "/bin/sh",
>>
>>                 "username": "cirros"
>>
>>             },
>>
>>             "runner": {
>>
>>                 "type": "constant",
>>
>>                 "times": 2,
>>
>>                 "concurrency": 1
>>
>>             },
>>
>>             "context": {
>>
>>                 "users": {
>>
>>                     "tenants": 1,
>>
>>                     "users_per_tenant": 1
>>
>>                 },
>>                 "neutron_network": {
>>                     "network_cidr": "10.%s.0.0/16"
>>                 }
>>
>>             }
>>
>>
>>
>>         }
>>
>>     ]
>>
>> }
>>
>>
>>
>>
>>  $rally -v task start
>> /home/alam/Desktop/rally/doc/samples/tasks/scenarios/vm/boot-runcommand-delete.json
>>
>> ================================================================================
>> Task  193a4b11-ec2d-4e36-ba53-23819e9d6bcf is started
>>
>> --------------------------------------------------------------------------------
>> 2014-09-07 17:23:00.680 2845 INFO rally.orchestrator.api [-] Benchmark
>> Task 193a4b11-ec2d-4e36-ba53-23819e9d6bcf on Deployment
>> 3cba9ee5-ef47-42f9-95bc-91107009a348
>> 2014-09-07 17:23:00.680 2845 INFO rally.benchmark.engine [-] Task
>> 193a4b11-ec2d-4e36-ba53-23819e9d6bcf | Starting:  Check cloud.
>> 2014-09-07 17:23:09.083 2845 INFO rally.benchmark.engine [-] Task
>> 193a4b11-ec2d-4e36-ba53-23819e9d6bcf | Completed: Check cloud.
>> 2014-09-07 17:23:09.084 2845 INFO rally.benchmark.engine [-] Task
>> 193a4b11-ec2d-4e36-ba53-23819e9d6bcf | Starting:  Task validation.
>> 2014-09-07 17:23:09.134 2845 INFO rally.benchmark.engine [-] Task
>> 193a4b11-ec2d-4e36-ba53-23819e9d6bcf | Starting:  Task validation of
>> scenarios names.
>> 2014-09-07 17:23:09.137 2845 INFO rally.benchmark.engine [-] Task
>> 193a4b11-ec2d-4e36-ba53-23819e9d6bcf | Completed: Task validation of
>> scenarios names.
>> 2014-09-07 17:23:09.138 2845 INFO rally.benchmark.engine [-] Task
>> 193a4b11-ec2d-4e36-ba53-23819e9d6bcf | Starting:  Task validation of syntax.
>>
>>
>> ================================================================================
>> Task 193a4b11-ec2d-4e36-ba53-23819e9d6bcf is failed.
>>
>> --------------------------------------------------------------------------------
>> <class 'rally.exceptions.InvalidBenchmarkConfig'>
>> Task config is invalid.
>>     Benchmark %(name)s has wrong configuration at position %(pos)s
>>     Reason: %(reason)s
>>     Benchmark configuration: %(config)s
>>
>>
>>
>>
>>
>> On Fri, Sep 5, 2014 at 7:46 PM, Ajay Kalambur (akalambu) <
>> akala...@cisco.com> wrote:
>>
>>>  Hi mason
>>> What is the task you want to perform run commands after vm boot or run
>>> performance
>>> Based on that I can help with correct pointer
>>> Ajay
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 5, 2014, at 2:28 AM, "masoom alam" <masoom.a...@gmail.com> wrote:
>>>
>>>  Please forward ur vmtasks.py file
>>>
>>> On Friday, September 5, 2014, masoom alam <masoom.a...@gmail.com> wrote:
>>>
>>>> http://paste.openstack.org/show/106297/
>>>>
>>>>
>>>> On Fri, Sep 5, 2014 at 1:12 PM, masoom alam <masoom.a...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks Ajay
>>>>>
>>>>>  I corrected this earlier. But facing another problem. Will forward
>>>>> paste in a while.
>>>>>
>>>>>
>>>>>
>>>>> On Friday, September 5, 2014, Ajay Kalambur (akalambu) <
>>>>> akala...@cisco.com> wrote:
>>>>>
>>>>>>  Sorry there was  typo in the patch should be @validation and not
>>>>>> @(validation
>>>>>> Please change that in vm_perf.py
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Sep 4, 2014, at 7:51 PM, "masoom alam" <masoom.a...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>   Why this is so when I patched with your sent patch:
>>>>>>
>>>>>>  http://paste.openstack.org/show/106196/
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 4, 2014 at 8:58 PM, Rick Jones <rick.jon...@hp.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 09/03/2014 11:47 AM, Ajay Kalambur (akalambu) wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>> Looking into the following blueprint which requires that network
>>>>>>>> performance tests be done as part of a scenario
>>>>>>>> I plan to implement this using iperf and basically a scenario which
>>>>>>>> includes a client/server VM pair
>>>>>>>>
>>>>>>>
>>>>>>>  My experience with netperf over the years has taught me that when
>>>>>>> there is just the single stream and pair of "systems" one won't actually
>>>>>>> know if the performance was limited by inbound, or outbound.  That is 
>>>>>>> why
>>>>>>> the likes of
>>>>>>>
>>>>>>> http://www.netperf.org/svn/netperf2/trunk/doc/examples/
>>>>>>> netperf_by_flavor.py
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> http://www.netperf.org/svn/netperf2/trunk/doc/examples/
>>>>>>> netperf_by_quantum.py
>>>>>>>
>>>>>>> apart from being poorly written python :)  Will launch several
>>>>>>> instances of a given flavor and then run aggregate tests on the Instance
>>>>>>> Under Test.  Those aggregate tests will include inbound, outbound,
>>>>>>> bidirectional, aggregate small packet and then a latency test.
>>>>>>>
>>>>>>> happy benchmarking,
>>>>>>>
>>>>>>> rick jones
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev@lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>>>> Sent from noir
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Sent from noir
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to