Re: [openstack-dev] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks
Thanks Yair,
I will dig into this more. I did try the "network" context, but same error.
regards
Behzad
On Tue, Oct 20, 2015 at 12:53 PM, Yair Fried <yfr...@redhat.com> wrote:
>
>
> On Tue, Oct 20, 2015 at 8:39 PM, Behzad Dastur <behzad.das...@gmail.com>
> wrote:
>
>> Hi Yair,
>> The rally version I am using is 0.1.2
>>
>> > rally --version
>> 0.1.2
>>
>> Also the task file is as shown below. Do you have an example of the
>> "network" context to skip creation on the interface on the xternal network?
>>
> have you seen the plugin reference?
> https://rally.readthedocs.org/en/latest/plugin/plugin_reference.html
> Looks like there's also existing_network [context] but I'm unfamiliar with
> it.
>
>> vagrant@rally:~/rally$ more /vagrant/boot.json
>>
>> {% set flavor_name = flavor_name or "m1.tiny" %}
>>
>> {
>>
>> "NovaServers.boot_server": [
>>
>> {
>>
>> "args": {
>>
>> "flavor": {
>>
>> "name": "{{flavor_name}}"
>>
>> },
>>
> "auto_assign_nic": true,
>
>> "image": {
>>
>> "name": "cirros-0.3.1-x86_64"
>>
>> },
>>
>> "use_floatingip": false
>>
> I think this should be true (or maybe even removed)
>
>> },
>>
>> "runner": {
>>
>> "type": "constant",
>>
>> "times": 10,
>>
>> "concurrency": 2
>>
>> },
>>
>> "context": {
>>
> "network": {"networks_per_tenant": 1},
>
>> "users": {
>>
>> "tenants": 3,
>>
>> "users_per_tenant": 2
>>
>> }
>>
>> }
>>
>> }
>>
>> ]
>>
>> }
>>
>> regards,
>> Behzad
>>
>> Date: Tue, 20 Oct 2015 15:04:46 +0300
>> From: Yair Fried <yfr...@redhat.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [rally] Rally boot tests fails with Error
>> Forbidden: It is not allowed to create an interface on external
>> networks
>> Message-ID:
>>
[openstack-dev] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks
I have a contrail/OpenStack cloud deployed on which I am trying to run some rally benchmarks. But I am having trouble getting the rally boot tests to run. It throws the "Error Forbidden: It is not allowed to create an interface on external network" It seems it is trying to create an interface on the external network, however in this case that operation is not required as the contrail plugin handles that. Is there a way to tell the rally scenario to avoid doing that. SImply put the operations that need to happen are: 1. nova boot (create private network/ or use private network provided) 2. neutron floating ip create, and assign it to the port eg (neutron floatingip-create --port-id ) Here is the error log: 2015-10-20 00:24:12.759 19075 INFO rally.plugins.openstack.context.keystone.users [-] Task 3000fcbd-2762-400d-920f-dfbfb667e7ec | Starting: Enter context: `users`2015-10-20 00:24:14.711 19075 INFO rally.plugins.openstack.context.keystone.users [-] Task 3000fcbd-2762-400d-920f-dfbfb667e7ec | Completed: Enter context: `users`2015-10-20 00:24:16.222 19264 INFO rally.task.runner [-] Task 3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 0 START2015-10-20 00:24:16.227 19264 INFO rally.task.runner [-] Task 3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 1 START2015-10-20 00:24:18.420 19264 INFO rally.task.runner [-] Task 3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 0 END: Error Forbidden: It is not allowed to create an interface on external network 2de28d39-34f9-48c5-bbac-609e258b7aad (HTTP 403) (Request-ID: req-fe32bcf8-f624-4a2d-a083-7b6c5d1f24ab) regards, Behzad __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks
Hi Yair,
The rally version I am using is 0.1.2
> rally --version
0.1.2
Also the task file is as shown below. Do you have an example of the
"network" context to skip creation on the interface on the xternal network?
vagrant@rally:~/rally$ more /vagrant/boot.json
{% set flavor_name = flavor_name or "m1.tiny" %}
{
"NovaServers.boot_server": [
{
"args": {
"flavor": {
"name": "{{flavor_name}}"
},
"image": {
"name": "cirros-0.3.1-x86_64"
},
"use_floatingip": false
},
"runner": {
"type": "constant",
"times": 10,
"concurrency": 2
},
"context": {
"users": {
"tenants": 3,
"users_per_tenant": 2
}
}
}
]
}
regards,
Behzad
Date: Tue, 20 Oct 2015 15:04:46 +0300
From: Yair Fried
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [rally] Rally boot tests fails with Error
Forbidden: It is not allowed to create an interface on external
networks
Message-ID:
Re: [openstack-dev] [rally][users]: Synchronizing between multiple scenario instances.
Hi Boris, I am still getting my feet wet with rally so some concepts are new, and did not quite get your statement regarding the different load generators. I am presuming you are referring to the Scenario runner and the different “types” of runs. What I was looking at is the runner, where we specify the type, times and concurrency. We could have an additional field(s) which would specify the synchronization property. Essentially, what I have found most useful in the cases where we run scenarios/tests in parallel; is some sort of “barrier”, where at a certain point in the run you want all the parallel tasks to reach a specific point before continuing. Also, I am also considering cases where synchronization is needed within a single benchmark case, where the same benchmark scenario: creates some vms, performs some tasks, deletes the vm Just for simplicity as a POC, I tried something with shared memory (multiprocessing.Value), which looks something like this: class Barrier(object): __init__(self, concurrency) self.shmem = multiprocessing.Value(‘I’, concurrency) self.lock = multiprocessing.Lock() def wait_at_barrier (): while self.shmem.value 0: time.sleep(1) return def decrement_shm_concurrency_cnt (): with self.lock: self.shmem.value -= 1 And from the scenario, it can be called as: scenario: -- do some action – barrobj.decrement_shm_concurrency_cnt() sync_helper.wait_at_barrier() -- do some action – -- all processes will do this action at almost the same time. I would be happy to discuss more to get a good common solution. regards, Behzad From: bo...@pavlovic.ru [mailto:bo...@pavlovic.ru] On Behalf Of Boris Pavlovic Sent: Tuesday, October 21, 2014 3:23 PM To: Behzad Dastur (bdastur) Cc: OpenStack Development Mailing List (not for usage questions); Pradeep Chandrasekar (pradeech); John Wei-I Wu (weiwu) Subject: Re: [openstack-dev] [rally][users]: Synchronizing between multiple scenario instances. Behzad, Unfortunately at this point there is no support of locking between scenarios. It will be quite tricky for implementation, because we have different load generators, and we will need to find common solutions for all of them. If you have any ideas about how to implement it in such way, I will be more than happy to get this in upstream. One of the way that I see is to having some kind of chain-of-benchmarks: 1) Like first benchmark is running N VMs 2) Second benchmarking is doing something with all those benchmarks 3) Third benchmark is deleting all these VMs (where chain elements are atomic actions) Probably this will be better long term solution. Only thing that we should understand is how to store those results and how to display them. If you would like to help with this let's start discussing it, in some kind of google docs. Thoughts? Best regards, Boris Pavlovic On Wed, Oct 22, 2014 at 2:13 AM, Behzad Dastur (bdastur) bdas...@cisco.commailto:bdas...@cisco.com wrote: Does rally provide any synchronization mechanism to synchronize between multiple scenario, when running in parallel? Rally spawns multiple processes, with each process running the scenario. We need a way to synchronize between these to start a perf test operation at the same time. regards, Behzad ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [rally][users]: Synchronizing between multiple scenario instances.
Does rally provide any synchronization mechanism to synchronize between multiple scenario, when running in parallel? Rally spawns multiple processes, with each process running the scenario. We need a way to synchronize between these to start a perf test operation at the same time. regards, Behzad ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally][users]
Hi Boris, Does rally provide any synchronization mechanism to synchronize between multiple scenario, when running in parallel? Rally spawns multiple processes, with each process running the scenario. We need a way to synchronize between these to start a perf test operation at the same time. regards, Behzad From: Boris Pavlovic [mailto:bpavlo...@mirantis.com] Sent: Wednesday, September 24, 2014 11:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [rally][users] Ajay, Ya adding support of benchmarking OpenStack clouds using ordinary user accounts that already exist is one of our majors goals for already more then half of year. As I said in my previous message, we will support it soon finally. Btw we have feature request page: https://github.com/stackforge/rally/tree/master/doc/feature_request With the list of features that we are working now. Best regards, Boris Pavlovic On Thu, Sep 25, 2014 at 5:30 AM, Ajay Kalambur (akalambu) akala...@cisco.commailto:akala...@cisco.com wrote: Hi Boris Existing users is one thing but according to Rally page it says admin account benchmarking is already supported Rally is on its way to support of benchmarking OpenStack clouds using ordinary user accounts that already exist. Rally lacked such functionality (it only supported benchmarking either from an admin account or from a bunch of temporarily created users), which posed a problem since some deployments don't allow temporary users creation. There have been twohttps://review.openstack.org/#/c/116766/ patcheshttps://review.openstack.org/#/c/119344/ that prepare the code for this new functionality. It is going to come very soon - stay tuned. Ajay From: Boris Pavlovic bpavlo...@mirantis.commailto:bpavlo...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, September 24, 2014 at 6:13 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [rally][users] Ajay, I am working that feature. It's almost ready. I'll let you know when I finish. Best regards, Boris Pavlovic On Thu, Sep 25, 2014 at 5:02 AM, Ajay Kalambur (akalambu) akala...@cisco.commailto:akala...@cisco.com wrote: Hi Our default mode of execution of rally is allowing Rally to create a new user and tenant. Is there a way to have rally use the existing admin tenant and user. I need to use Rally for some tests which would need a admin access so I would like Rally to use existing admin tenant and admin user for tests Ajay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
