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) <akala...@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.a...@gmail.com> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, September 2, 2014 at 11:12 PM > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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) < > akala...@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 <bo...@pavlovic.me> >> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Friday, August 29, 2014 at 2:08 PM >> >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> Cc: "Harshil Shah (harsshah)" <harss...@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 < >> tnurlygaya...@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) < >>> akala...@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@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@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 >> >> > > _______________________________________________ > 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