Open Stack

Ajay,

Oh looks you are working hard on Rally. I am excited about your patches.

By the way, one small advice is to share results and ideas that you have
with community ASAP.
it's perfectly to publish "not ideal" patches on review even if they don't
have unit tests and doesn't work at all.
Because community can help with advices and safe a lot of your time.


2. Scenario for booting Vms on every compute node in the cloud….This has a
> dependency right now this is admin access. So for this I need Item 3
> 3. Provide an ability to make rally created users have admin access for
> things like forced host scheduling . Planning to add this to user context



Not quite sure that you need point 3. If you put on scenario:
@validation.required_openstack(admin=True, users=True).
You'll have admin in scenario. So you can execute from him commands. E.g.:

self.admin_clients("neutron").... (it's similar to self.clients but with
admin access)

That's how live_migrate benchmark is implemented:
https://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/nova/servers.py#L253

 Does this make sense?


4. Iperf scenario we discussed


Nice!


Best regards,
Boris Pavlovic






On Fri, Dec 19, 2014 at 4:06 AM, Ajay Kalambur (akalambu) <
akalambu at cisco.com> wrote:
>
>  I created a new scenario which scales on network and VM at same time.
> If you have no objection I would like to send out a review this week
> I actually have following reviews to do next week
>
>    1. Scenario for network stress I.e VM+ network with subnet with unique
>    cidr. So in future we can add a router to this and do apt-get update from
>    all Vms and test network scale
>    2. Scenario for booting Vms on every compute node in the cloud….This
>    has a dependency right now this is admin access. So for this I need Item 3
>    3. Provide an ability to make rally created users have admin access
>    for things like forced host scheduling . Planning to add this to user
>    context
>    4. Iperf scenario we discussed
>
> If you have objection to these I can submit reviews for these. Have the
> code need to write unit tests for the scenarios since looking at other
> reviews that seems to be the case
>
>  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: Thursday, December 18, 2014 at 2:16 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [rally] Rally scenario for network scale
> with VMs
>
>   Ajay,
>
>  Sorry for long reply.
>
>  At this point Rally supports only benchmarking from temporary created
> users and tenants.
>
>  Fortunately today we merged this Network context class:
> https://review.openstack.org/#/c/103306/96
> it creates any amount of networks for each rally temporary tenant.
>
>  So basically you can use it and extend current benchmark scenarios in
> rally/benchmark/scenarios/nova/ or add new one that will attach N networks
> to created VM (which is just few lines of code). So task is quite easy
> resolvable now.
>
>
>  Best regards,
> Boris Pavlovic
>
>
> On Wed, Nov 26, 2014 at 9:54 PM, Ajay Kalambur (akalambu) <
> akalambu at cisco.com> wrote:
>>
>>  Hi
>> Is there  a Rally scenario under works where we create N networks and
>> associate N Vms with each network.
>> This would be a decent stress tests of neutron
>> Is there any such scale scenario in works
>> I see scenario for N networks, subnet creation and a separate one for N
>> VM bootups
>> I am looking for an integration of these 2
>>
>>
>>
>>  Ajay
>>
>> _______________________________________________
>> 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/20141219/a0940240/attachment.html>