Open Stack

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<mailto:masoom.alam at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto:boris at pavlovic.me>>

Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto:openstack-dev at lists.openstack.org>>
Cc: "Harshil Shah (harsshah)" <harsshah at cisco.com<mailto: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<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc

[http://www.openstacksv.com/]<http://www.openstacksv.com/>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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<mailto: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/3736290a/attachment.html>