Re: [openstack-dev] [rally] "Failed to create the requested number of tenants" error

[Aleksandr Maretskiy]

Nate,

please try to make this simple check to make sure that everything is set up
properly:

1) command "rally deployment check" should print an ascii-table with a list
of services available
2) load rally auto-generated openrc file and run some OpenStack CLI command,
for example:

  $ . ~/.rally/openrc
  $ openstack network list   # does this work as expected?

Also, make sure that value of "auth_url" in Rally deployment configuration
(this can be obtained via command "rally deployment config") is correct.
Please use correct deployment configuration in opposite to envvars like
OS_AUTH_URL while using Rally


On Fri, Jun 10, 2016 at 5:25 PM, Nate Johnston 
wrote:

> Boris,
>
> We use a common Keystone across all of our production environments; I
> was running this against a new deployment we are working on making
> production-ready, so I had specified OS_AUTH_URL to be the common
> keystone.  There is no keystone deployed in this datacenter.
>
> Is there a specific way I need to tweak Rally for that kind of setup?
>
> Thanks,
>
> --N.
>
> P.S. Sending you the catalog under separate cover.
>
> Thu, Jun 09, 2016 at 10:15:09PM -0700, Boris Pavlovic wrote:
> > Nate,
> >
> > This looks quite strange. Could you share the information from keystone
> > catalog?
> >
> > Seems like you didn't setup admin endpoint for keystone in that region.
> >
> > Best regards,
> > Boris Pavlovic
> >
> > On Thu, Jun 9, 2016 at 12:41 PM, Nate Johnston 
> > wrote:
> >
> > > Rally folks,
> > >
> > > I am working with an engineer to get him up to speed on Rally on a new
> > > development.  He is trying out running a few tests from the samples
> > > directory, like samples/tasks/scenarios/nova/list-hypervisors.yaml -
> but
> > > he keeps getting the error "Completed: Exit context: `users`\nTask
> > > config is invalid: `Unable to setup context 'users': 'Failed to create
> > > the requested number of tenants.'`"
> > >
> > > This is against an Icehouse environment with Mitaka Rally; When I run
> > > Rally with debug logging I see:
> > >
> > > 2016-06-08 18:59:24.692 11197 ERROR rally.common.broker
> EndpointNotFound:
> > > admin endpoint for identity service in  region not found
> > >
> > > However I note that $OS_AUTH_URL is set in the Rally deployment... see
> > > http://paste.openstack.org/show/509002/ for the full log.
> > >
> > > Any ideas you could give me would be much appreciated.  Thanks!
> > >
> > > --N.
> > >
> > >
> > >
> > >
> __
> > > 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
> > >
>
> >
> __
> > 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
>
>
> __
> 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
>
__
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] Term "workload" has two clashing meanings

[Aleksandr Maretskiy]

"dataplane" looks good to me

On Mon, Apr 11, 2016 at 10:56 PM, Boris Pavlovic  wrote:

> Alex,
>
> I would suggest to call it "dataplane" because it obvious points to
> dataplane testing
>
> Best regards,
> Boris Pavlovic
>
> On Mon, Apr 11, 2016 at 11:10 AM, Roman Vasilets 
> wrote:
>
>> Hi all, personally I want to suggest* crossload. *Concept is similar to
>> cross training(training in two or more sports in order to improve
>> fitness and performance, especially in a main sport.) in sport. By that
>> template - crossload is load in two or more areas in order to improve
>> durability and performance, especially in a main area.
>> Thanks, Roman.
>>
>> On Mon, Apr 11, 2016 at 6:38 PM, Aleksandr Maretskiy <
>> amarets...@mirantis.com> wrote:
>>
>>> Hi all,
>>>
>>> this is about terminology, we have term "workload" in Rally that appears
>>> in two clashing meanings:
>>>
>>>  1. module rally.plugins.workload
>>> <https://github.com/openstack/rally/tree/master/rally/plugins/workload>
>>> which collects plugins for cross-VM testing
>>>  2. workload replaces term "scenario" in our new input task format
>>> <https://github.com/openstack/rally/blob/master/doc/specs/in-progress/new_rally_input_task_format.rst>
>>> (task->scenarios is replaced with task->subtasks->workloads)
>>>
>>> Let's introduce new term as replacement of "1." (or maybe "2." but I
>>> suppose this is not the best option).
>>>
>>> Maybe rename rally.plugins.workload to:
>>>rally.plugins.
>>> *vmload   *rally.plugins.*vmperf*
>>>rally.plugins.*shaker*
>>>rally.plugins.*vmworkload*
>>>...more ideas?
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
>
__
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

[openstack-dev] [Rally] Term "workload" has two clashing meanings

[Aleksandr Maretskiy]

Hi all,

this is about terminology, we have term "workload" in Rally that appears in
two clashing meanings:

 1. module rally.plugins.workload

which collects plugins for cross-VM testing
 2. workload replaces term "scenario" in our new input task format

(task->scenarios is replaced with task->subtasks->workloads)

Let's introduce new term as replacement of "1." (or maybe "2." but I
suppose this is not the best option).

Maybe rename rally.plugins.workload to:
   rally.plugins.
*vmload   *rally.plugins.*vmperf*
   rally.plugins.*shaker*
   rally.plugins.*vmworkload*
   ...more ideas?
__
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] single router per tenant in network context

[Aleksandr Maretskiy]

Hi,

network context creates router for each network automatically, so you can
not reduce the number of routers with this context
https://github.com/openstack/rally/blob/master/rally/plugins/openstack/context/network/networks.py#L79

However you can create and use own network context plugin, inherited from
https://github.com/openstack/rally/blob/master/rally/plugins/openstack/context/network/networks.py#L31
and override its setup() method - create single router per tenant and then
attach it to each created network, like here
https://github.com/openstack/rally/blob/master/rally/plugins/openstack/wrappers/network.py#L342-L343

Ask me if you need more help


On Tue, Mar 15, 2016 at 7:58 PM, Akshay Kumar Sanghai <
akshaykumarsang...@gmail.com> wrote:

> Hi,
> I have a openstack setup with 1 controller node, 1 network node and 2
> compute nodes. I want to perform scale testing of the setup in the
> following manner:
>
> - Create 10 tenants
> - Create 1 router per tenant
> - Create 100 neutron networks across 10 tenants attached to the router
> - Create 500 VMs spread across 10 tenants attached to the networks
>
> I used the boot_server scenario and defined the number of networks and
> tenants in the network and users context respectively. But I want only one
> router to be created per tenant. In the current case, one router is created
> per network.
>
> Do i have an option to accomplish this using the existing rally code? Or
> should i go ahead and make some change in the network context for my use
> case?
>
> Thanks,
> Akshay
>
> __
> 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
>
>
__
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] [Openstack] Error while using Rally with Python

[Aleksandr Maretskiy]

Hi

try this:

  # It is important to have these lines first!!!
  from rally.common import db
  db.api.db_options.set_defaults(db.api.CONF,
connection='sqlite:///path/to/your/rally.sqlite')

  # now run your code


On Tue, Feb 2, 2016 at 12:47 PM, varun bhatnagar 
wrote:

> Hi,
>
> I am trying out Rally with Python and I have written a very small snippet
> of code to register the deployment
>
> from rally.api import Deployment
> deploymentObject = Deployment()
> deploymentObject.create({
> "type": "ExistingCloud",
> "auth_url": "http://192.168.136.145:5000/v2.0";,
> "region_name": "RegionOne",
> "endpoint_type": "public",
> "admin": {
> "username": "admin",
> "password": "admin",
> "tenant_name": "admin"
> },
> "https_insecure": "false",
> "https_cacert": ""
> }, "MyCloud")
>
>
> but it is throwing an error.
>
>   File
> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line
> 450, in do_execute
> cursor.execute(statement, parameters)
> sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such table:
> deployments [SQL: u'INSERT INTO deployments (created_at, updated_at, uuid,
> parent_uuid, name, started_at, completed_at, config, admin, users,
> enum_deployments_status) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)']
> [parameters: ('2016-02-02 10:39:46.549138', '2016-02-02 10:39:46.549149',
> '7f56f359-4001-42ee-a60f-fbe9023f7dc7', None, 'ExistingCloud', None, None,
> '{"endpoint_type": "public", "auth_url": "http://192.168.136.145:5000/v2.0";,
> "region_name": "RegionOne", "https_insecure": "false", "admin":
> {"username": "admin", "tenant_name": "admin", "password": "admin"}, "type":
> "ExistingCloud", "https_cacert": ""}', None,  0x7f8fd25b9ae0, size -1, offset 0 at 0x7f8fd20ac2b0>, 'deploy->init')]
>
> Can anyone please help.
>
> BR,
> Varun
>
> __
> 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
>
>
__
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] Failure running rally unit tests

[Aleksandr Maretskiy]

Hi

The problem is definitely in mock - some part of keystoneclient package is
actually called (having a real api request) but it should be mocked instead.
Unit test expects that keystoneclient.v2_0 is discovered, but we have
something else instead.

In latest rally version this unit test works fine (I've checked this right
now).

It is important to have real code available to make deeper investigation,
since you use custom package rhos-cert-client/tests/rhcert/suites/openstack/
is based on rally code, but osclients.py significantly differs from its
brother from rally project (according to line numbers from paste).

Can you provide your modules osclients.py and test_osclients.py?



On Fri, Jan 29, 2016 at 11:59 AM, Sudhir Verma  wrote:

> Hi,
>
> I am running the rally test
> https://github.com/openstack/rally/blob/master/tests/unit/test_osclients.py#L87
> there is a function "test_create_keystone_client_v2"
> when i am testing that function i am getting an error i.e:
> "keystoneclient.openstack.common.apiclient.exceptions.ConnectionRefused:
> Unable to establish connection to http://auth_url";
>
> The error is:
> http://paste.openstack.org/show/485380/
>
> Thanks & Regards,
> Sudhir Verma
>
> __
> 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
>
__
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] [Fuel] Getting rid of Docker containers on the Fuel master node

[Aleksandr Maretskiy]

On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya 
wrote:

> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> > Hi all,
> >
> > as you know, Rally runs inside docker on Fuel master node, so docker
> > removal (good improvement) is a problem for Rally users.
> >
> > To solve this, I'm planning to make native Rally installation on Fuel
> > master node that is running on CentOS 7,
> > and then make a step-by-step instruction how to make this installation.
> >
> > So I hope docker removal will not make issues for Rally users.
>
> I believe the most backwards compatible scenario is to keep the docker
> installed while removing the fuel-* docker things back to the host OS.
> So nothing would prevent user from pulling and running whichever docker
> containers he wants to put on the Fuel master node. Makes sense?
>
>
Sounds good
__
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] [Fuel] Getting rid of Docker containers on the Fuel master node

[Aleksandr Maretskiy]

Hi all,

as you know, Rally runs inside docker on Fuel master node, so docker
removal (good improvement) is a problem for Rally users.

To solve this, I'm planning to make native Rally installation on Fuel
master node that is running on CentOS 7,
and then make a step-by-step instruction how to make this installation.

So I hope docker removal will not make issues for Rally users.

On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> ETA:
>
> experimental ISO w/o docker: tonight
> spec: tomorrow night
>
>
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> @Vova,
>> thanks for bringing this up.
>> The new approach without docker containers on master node really has many
>> advantages.
>>
>> @Igor,
>> regarding your question, I would say that we have many dependencies from
>> containers in CI/CD systems and test's codebase. The test alignment to the
>> new implementation won't be easy. In such things we should move forward
>> step by step.
>> As you know the first step is a spec file, can you give us a link to it?
>>
>>
>> Nastya.
>>
>> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh 
>> wrote:
>>
>>> With CentOS7 we will have python2.7 at Fuel Admin node as a default
>>> version, I believe.
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh,
>>> Principal Engineer
>>> Mirantis
>>>
>>> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
>>> tnurlygaya...@mirantis.com> wrote:
>>>
 Hi Andrey,

 As far as I remember from the last usage of fuel master node, there was
> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
> hard to launch some application on fuel node without docker (image with
> py27/py3). Are you planning to provide py27 at least or my note is 
> outdated
> and I can already use py27 from the box?

 We can install docker on master node anyway to run Rally / Tempest or
 other test suites and scripts from master node with Python 2.7 or something
 also.

 On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin 
 wrote:

> Hi!
> I'm not fuel developer, so opinion below is based on user-view.
> As far as I remember from the last usage of fuel master node, there
> was Centos + py26 installation. Python 2.6 is old enough and sometimes it
> is hard to launch some application on fuel node without docker (image with
> py27/py3). Are you planning to provide py27 at least or my note is 
> outdated
> and I can already use py27 from the box?
>
> On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> As might remember, we introduced Docker containers on the master node
>> a while ago when we implemented first version of Fuel upgrade feature. 
>> The
>> motivation behind was to make it possible to rollback upgrade process if
>> something goes wrong.
>>
>> Now we are at the point where we can not use our tarball based
>> upgrade approach any more and those patches that deprecate upgrade 
>> tarball
>> has been already merged. Although it is a matter of a separate 
>> discussion,
>> it seems that upgrade process rather should be based on kind of backup 
>> and
>> restore procedure. We can backup Fuel data on an external media, then we
>> can install new version of Fuel from scratch and then it is assumed 
>> backed
>> up Fuel data can be applied over this new Fuel instance. The procedure
>> itself is under active development, but it is clear that rollback in this
>> case would be nothing more than just restoring from the previously backed
>> up data.
>>
>> As for Docker containers, still there are potential advantages of
>> using them on the Fuel master node, but our current implementation of the
>> feature seems not mature enough to make us benefit from the
>> containerization.
>>
>> At the same time there are some disadvantages like
>>
>>- it is tricky to get logs and other information (for example,
>>rpm -qa) for a service like shotgun which is run inside one of 
>> containers.
>>- it is specific UX when you first need to run dockerctl shell
>>{container_name} and then you are able to debug something.
>>- when building IBP image we mount directory from the host file
>>system into mcollective container to make image build faster.
>>- there are config files and some other files which should be
>>shared among containers which introduces unnecessary complexity to the
>>whole system.
>>- our current delivery approach assumes we wrap into rpm/deb
>>packages every single piece of the Fuel system. Docker images are not 
>> an
>>exception. And as far as they depend on other rpm packages we forced 
>> to
>> 

Re: [openstack-dev] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Aleksandr Maretskiy]

Behzad, please run rally task start with `--debug' option and then provide
us with some details (traceback, etc) about this error.

Also Yair suggested to put `"auto_assign_nic": true' into scenario config -
that is good idea.
Get rid of `use_floatingip' - this parameter is not used for this scenario.

On Wed, Oct 21, 2015 at 6:23 PM, Behzad Dastur 
wrote:

> 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  wrote:
>
>>
>>
>> On Tue, Oct 20, 2015 at 8:39 PM, Behzad Dastur 
>> 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 
>>> 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:
>>> >> rejjeirq8m630049woa...@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>>
>>> On Tue, Oct 20, 2015 at 2:06 PM, Behzad Dastur 
>>> wrote:
>>>
>>> > 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.
>>> >
>>> What version of Rally are you using?
>>> Could you please provide your task file? Looks like you are explicitly
>>> telling rally to use your external network for the VMs.
>>>
>>>
>>> >  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)
>>> >
>>> The "network" context should allow you to dynamically create the
>>> networks.
>>> Also, all scenarios that boot an instance can propagate boot arguments
>>> even
>>> if they aren't explicitly listed (for more details try "$ rally plugin
>>> info
>>> "), so you should be able to pass "{networks: {uuid: }}"
>>> to the scenario.
>>>
>>> 2. neutron floating ip create, and assign it to the port eg (neutron
>>> > floatingip-create --port-id  >> net=""
>>> > id="">)
>>> >
>>> Only in VMTask AFAIK.
>>>
>>>
>>> > 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-7b6c5d1

Re: [openstack-dev] [openstack-operators][Rally] Rally plugins reference is available

[Aleksandr Maretskiy]

Cool!

On Fri, Sep 25, 2015 at 3:05 AM, Boris Pavlovic  wrote:

> Hi stackers,
>
> As far as you know Rally test cases are created as a mix of plugins.
>
> At this point of time we have more than 200 plugins for almost all
> OpenStack projects.
> Before you had to analyze code of plugins or use "rally plugin find/list"
> commands to find plugins that you need, which was the pain in neck.
>
> So finally we have auto generated plugin reference:
> https://rally.readthedocs.org/en/latest/plugin/plugin_reference.html
>
>
> Best regards,
> Boris Pavlovic
>
> __
> 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
>
>
__
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] [opentack-dev][meetings] Proposing changes in Rally meetings

[Aleksandr Maretskiy]

Agreed with everything, but I think it would be a bit better if move one
meeting from Monday to another day (Andrey K. is right)


On Fri, Apr 17, 2015 at 5:35 PM, Andrey Kurilin 
wrote:

> >  - We should start making agenda for each meeting and publish it to
> Rally wiki
>
> +1
>
> > * Second is release management meeting, where we are discussing
> priorities for
> >   current & next release. So core team will know what to review
> first.
>
> It would be nice to post list of high priority patches to etherpad or
> google docs after each meeting
>
> >  - Move meetings from #openstack-meeting to #openstack-rally chat.
>
> doesn't matter for me:)
>
> >   - We should adjust better time for current Rally team.
>
> yeah. Current time is not good:( +1 for 15:00 UTC
>
> >  - Do meetings every Monday and Wednesday
>
> Monday?) Monday is very hard day...
>
> On Fri, Apr 17, 2015 at 4:26 PM, Boris Pavlovic  wrote:
>
>> Rally team,
>>
>>
>> I would like to propose next changes in Rally meetings:
>>
>>   - We should start making agenda for each meeting and publish it to
>> Rally wiki
>>
>>   - We should do 2 meeting per week:
>>
>>  * First is regular meeting (like we have now) where we are
>> discussing everything
>>
>>  * Second is release management meeting, where we are discussing
>> priorities for
>>current & next release. So core team will know what to review
>> first.
>>
>>   - Move meetings from #openstack-meeting to #openstack-rally chat.
>>
>>   - We should adjust better time for current Rally team. Like at the
>> moment it is too late
>>  for few of cores in Rally. it's 17:00 UTC and I would like to
>> suggest to make at 15:00 UTC.
>>
>>   - Do meetings every Monday and Wednesday
>>
>>
>> Thoughts ?
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
__
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] [docs][rally] Rally template tasks in a nutshell

[Aleksandr Maretskiy]

Great improvement! Thanks!

On Tue, Apr 7, 2015 at 1:17 PM, Mikhail Dubov  wrote:

> Hi stackers,
>
> as you might remember, we have recently added a nice feature to Rally
> which is the support of *task templates*. Rally uses the template syntax
> based on *Jinja2*, and thus makes it simple to parameterize your
> benchmark task files.
>
> Our step-by-step tutorial has just been updated with a new lesson devoted
> to task templates in Rally:
> http://rally.readthedocs.org/en/latest/tutorial/step_8_task_templates.html
>
> You are welcome to read it through (it is fairly short) and ask any
> questions.
>
> Best regards,
> Mikhail Dubov
>
> Engineering OPS
> Mirantis, Inc.
> E-Mail: mdu...@mirantis.com
> Skype: msdubov
>
> __
> 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
>
>
__
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] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

[Aleksandr Maretskiy]

The idea is great, but IMHO we can move all project-specific code out of
rally, so:

  * rally plugin should be a part of project (for example, located in
functional tests directory)
  * use {project url} instead of {project name} in rally verify command,
example:

$ rally verify https://github.com/openstack/nova start


On Tue, Mar 10, 2015 at 6:01 PM, Timur Nurlygayanov <
tnurlygaya...@mirantis.com> wrote:

> Hi,
>
> I like this idea, we use Rally for OpenStack clouds verification at scale
> and it is the real issue - how to run all functional tests from each
> project with the one script. If Rally will do this, I will use Rally to run
> these tests.
>
> Thank you!
>
> On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent  wrote:
>
>> On Mon, 9 Mar 2015, Davanum Srinivas wrote:
>>
>>  2. Is there a "test" project with Gabbi based tests that you know of?
>>>
>>
>> In addition to the ceilometer tests that Boris pointed out gnocchi
>> is using it as well:
>>
>>https://github.com/stackforge/gnocchi/tree/master/gnocchi/tests/gabbi
>>
>>  3. What changes if any are needed in Gabbi to make this happen?
>>>
>>
>> I was unable to tell from the original what "this" is and how gabbi
>> is involved but the above link ought to be able to show you how
>> gabbi can be used. There's also the docs (which could do with some
>> improvement, so suggestions or pull requests welcome):
>>
>>http://gabbi.readthedocs.org/en/latest/
>>
>> --
>> Chris Dent tw:@anticdent freenode:cdent
>> https://tank.peermore.com/tanks/cdent
>>
>> 
>> __
>> 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
>>
>
>
>
> --
>
> Timur,
> Senior QA Engineer
> OpenStack Projects
> Mirantis Inc
>
> __
> 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
>
>
__
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] [openstack-operators][Rally][HA-testing][multi-scenarios-load-gen] Proposal to change Rally input task format

[Aleksandr Maretskiy]

Hi

Patch set #3 looks good for me (but I have a proposal about `description'
field).

Thanks!

On Fri, Feb 27, 2015 at 2:02 PM, Mikhail Dubov  wrote:

> Hi Boris,
>
> nice job! I like how this new task format looks like. I have commented
> your patch with a couple of suggestions to make it even easier to
> understand.
>
> Best regards,
> Mikhail Dubov
>
> Engineering OPS
> Mirantis, Inc.
> E-Mail: mdu...@mirantis.com
> Skype: msdubov
>
> On Thu, Feb 26, 2015 at 12:24 AM, Boris Pavlovic 
> wrote:
>
>> Hi stackers,
>>
>>
>> When we started Rally we have a just small idea to make some tool that
>> generates load and measures performance. During almost 2 years a lot of
>> changed in Rally, so now it's quite common testing framework that allows to
>> cover various topics like: stress, load, volume, performance, negative,
>> functional testing. Since the begging we have idea of "scenario" centric
>> approach, where scenario method that is called multiple times
>> simultaneously to generate load and duration of it is collected.
>>
>> This is huge limitation that doesn't allow us to easily generate real
>> life load. (e.g. loading simultaneously few components) or HA testing
>> (where we need during the load generation to disable/kill process, reboot
>> or power off physical nodes). To make this possible we should just run
>> multiple scenarios in parallel, but this change will require change in
>> input task format.
>>
>> I made proposal of new Rally task input format in this patch:
>>
>> https://review.openstack.org/#/c/159065/3/specs/new_rally_input_task_format.yaml
>>
>> Please review it. Let's try to resolve all UX issues before starting
>> working on it.
>>
>> P.S. I hope this will be the last big change in Rally input task format..
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
>
__
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