Open Stack

Mike,


I understand your concern about keeping the number of different benchmark
> scenarios in Rally not too big so that users don't get confused. But what I
> really like now about benchmark scenario names in Rally is that they are
> highly declarative, i.e. you read them and you have a clear idea of what's
> going on inside those scenarios. You see "boot_and_delete_server" => you
> know that Rally will boot and then delete a server, "boot_server" => only
> boot a server.



"do_delete" is as well quite clear for understanding.

This will solve 2 more issues.

1) Now we have benchmarks that are creating a lot of resources. And it's
not clear are we deleting everything or just single resource.
2) Inconsistence in naming (there are part of benchmarks that deletes
resources but don't have delete in name)


In any case this reduce huge duplication of code with should be nice IMHO.

Best regards,
Boris Pavlovic

On Sun, Jan 18, 2015 at 7:18 PM, Mikhail Dubov <mdubov at mirantis.com> wrote:

> Hi Boris,
>
> I understand your concern about keeping the number of different benchmark
> scenarios in Rally not too big so that users don't get confused. But what I
> really like now about benchmark scenario names in Rally is that they are
> highly declarative, i.e. you read them and you have a clear idea of what's
> going on inside those scenarios. You see "boot_and_delete_server" => you
> know that Rally will boot and then delete a server, "boot_server" => only
> boot a server.
>
> That's very convenient e.g. when you navigate through Rally report pages:
> you see the scenario names in the left panel and you know what to expect
> from their results. It seems to me that, if we merge scenarios like "boot_server"
> and "boot_and_delete_server" together, we will lose a bit in clarity.
>
> Besides, as you pointed out, "Nova.boot_server" and "Nova.boot_and_delete_server"
> are used for two different purposes - seems to be indeed a strong reason
> for keeping them separated.
>
> Best regards,
> Mikhail Dubov
>
> Engineering OPS
> Mirantis, Inc.
> E-Mail: mdubov at mirantis.com
> Skype: msdubov
>
> On Sat, Jan 17, 2015 at 8:47 PM, Boris Pavlovic <boris at pavlovic.me> wrote:
>
>> Hi stackers,
>>
>> I have an idea about removing almost half of rally scenarios and keep all
>> functionality.
>>
>> Currently you can see a lot of similar benchmarks like:
>>
>> NovaServers.boot_server                      # boot server with passed
>> arguments
>> NovaServers.boot_and_delete_server  # boot server with passed arguments
>> and delete
>>
>> The reason of having this 2 benchmarks are various purpose of them:
>>
>> 1) Nova.boot_server is used for *volume/scale testing*.
>> Where we would like to see how N active VM works and affects OpenStack
>> API and booting next VMs.
>>
>> 2) Nova.boot_and_delete_server is used for *performance/load* testing.
>> We are interested how booting and deleting VM perform in case on various
>> load (what is different in duration of booting 1 VM when we have 1, 2, M
>> simultaneously VM boot actions)
>>
>>
>> *The idea is to keep only 1 boot_server and add arguments "do_delete"
>> with by default False. *
>>
>> It means that:
>>
>>  # this is equal to old Nova.boot_server
>> NovaServers.boot_server: [{"args": {...} }]
>>
>> # this is equal to old Nova.boot_and_delete_server
>> NovaServers.boot_server: [{"args": {..., do_delete: True}]
>>
>>
>> Thoughts?
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150119/0af61b29/attachment.html>