Open Stack

Please pass on your VMTasks.py. Further, floating ips are available.

Thanks for the help!


On Wed, Sep 3, 2014 at 8:07 PM, Ajay Kalambur (akalambu) <akalambu at cisco.com
> wrote:

>  The reason this is failing is you are specifying a fixed network and at
> the same time asking for a new network to be created using context. What
> happens is the VM gets attached to your fixed network instead of the
> created Rally network
> So you need to modify vm_tasks.py for this case and basically if not fixed
> and using floating ip just skip the network check and the fixed ip code and
> just directly use floating ip to access.
> I think some changes are needed to vm_tasks.py to make it work for both
> fixed and floating and support for network context
>
>
>  If you need a local change I can pass along a local change for
> vm_tasks.py that only support floating ip. Let me know do you have floating
> ips available ?
> Ajay
>
>
>   From: masoom alam <masoom.alam at gmail.com>
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, September 2, 2014 at 11:12 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Rally scenario Issue
>
>   Hi Ajay,
>
>  We are testing the same scenario that you are working one, but getting
> the follow error:
>
>  http://paste.openstack.org/show/105029/
>
>  Could you be of any help here?
>
>  Thanks
>
>
>
>
> On Wed, Sep 3, 2014 at 4:16 AM, Ajay Kalambur (akalambu) <
> akalambu at cisco.com> wrote:
>
>>  Hi Guys
>> For the throughput tests I need to be able to install iperf on the cloud
>> image. For this DNS server needs to be set. But the current network context
>> should also support DNS name server setting
>> Should we add that into network context?
>> Ajay
>>
>>
>>
>>   From: Boris Pavlovic <boris at pavlovic.me>
>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>>  Date: Friday, August 29, 2014 at 2:08 PM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> Cc: "Harshil Shah (harsshah)" <harsshah at cisco.com>
>> Subject: Re: [openstack-dev] Rally scenario Issue
>>
>>   Timur,
>>
>>  Thanks for pointing Ajay.
>>
>>  Ajay,
>>
>>   Also I cannot see this failure unless I run rally with –v –d object.
>>
>>
>>  Actually rally is sotring information about all failures. To get
>> information about them you can run next command:
>>
>>  *rally task results --pprint*
>>
>>  It will display all information about all iterations (including
>> exceptions)
>>
>>
>>   Second when most of the steps in the scenario failed like attaching to
>>> network, ssh and run command why bother reporting the results
>>
>>
>>  Because, bad results are better then nothing...
>>
>>
>>  Best regards,
>> Boris Pavlovic
>>
>>
>> On Sat, Aug 30, 2014 at 12:54 AM, Timur Nurlygayanov <
>> tnurlygayanov at mirantis.com> wrote:
>>
>>>   Hi Ajay,
>>>
>>>  looks like you need to use NeutronContext feature to configure Neutron
>>> Networks during the benchmarks execution.
>>>  We now working on merge of two different comits with NeutronContext
>>> implementation:
>>> https://review.openstack.org/#/c/96300  and
>>> https://review.openstack.org/#/c/103306
>>>
>>>  could you please apply commit https://review.openstack.org/#/c/96300
>>> and run your benchmarks? Neutron Network with subnetworks and routers will
>>> be automatically created for each created tenant and you should have the
>>> ability to connect to VMs. Please, note, that you should add the following
>>> part to your task JSON to enable Neutron context:
>>> ...
>>> "context": {
>>>     ...
>>>     "neutron_network": {
>>>         "network_cidr": "10.%s.0.0/16",
>>>     }
>>> }
>>> ...
>>>
>>>  Hope this will help.
>>>
>>>
>>>
>>>  On Fri, Aug 29, 2014 at 11:42 PM, Ajay Kalambur (akalambu) <
>>> akalambu at cisco.com> wrote:
>>>
>>>>   Hi
>>>> I am trying to run the Rally scenario boot-runcommand-delete. This
>>>> scenario has the following code
>>>>   def boot_runcommand_delete(self, image, flavor,
>>>>                                script, interpreter, username,
>>>>                                fixed_network="private",
>>>>                                floating_network="public",
>>>>                                ip_version=4, port=22,
>>>>                                use_floatingip=True, **kwargs):
>>>>    server = None
>>>>         floating_ip = None
>>>>         try:
>>>>             print "fixed network:%s floating network:%s"
>>>> %(fixed_network,floating_network)
>>>>             server = self._boot_server(
>>>>                 self._generate_random_name("rally_novaserver_"),
>>>>                 image, flavor, key_name='rally_ssh_key', **kwargs)
>>>>
>>>>  *            self.check_network(server, fixed_network)*
>>>>
>>>>  The question I have is the instance is created with a call to
>>>> boot_server but no networks are attached to this server instance. Next step
>>>> it goes and checks if the fixed network is attached to the instance and
>>>> sure enough it fails
>>>> At the step highlighted in bold. Also I cannot see this failure unless
>>>> I run rally with –v –d object. So it actually reports benchmark scenario
>>>> numbers in a table with no errors when I run with
>>>> rally task start boot-and-delete.json
>>>>
>>>>  And reports results. First what am I missing in this case. Thing is I
>>>> am using neutron not nova-network
>>>> Second when most of the steps in the scenario failed like attaching to
>>>> network, ssh and run command why bother reporting the results
>>>>
>>>>  Ajay
>>>>
>>>>
>>>>  _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>  Timur,
>>> QA Engineer
>>> OpenStack Projects
>>> Mirantis Inc
>>>
>>> [image: http://www.openstacksv.com/] <http://www.openstacksv.com/>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140903/dceae4ab/attachment.html>