Re: [openstack-dev] [rally] Moving OpenStack plugins into separate repo

Andrey, Great news! Best regards, Boris Pavlovic On Wed, Apr 11, 2018 at 9:14 AM, Andrey Kurilin wrote: > Hi Stackers! > > Today I am happy to announce great news! > > From a historical perspective, Rally is testing (benchmarking) tool for > OpenStack, but it is changed. M

Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

ads in parallel (and generate more realistic load) -. So it would be really nice if you can share gaps that you faced that are blocking you to use directly Rally.. Thanks! Best regards, Boris Pavlovic On Tue, Oct 31, 2017 at 10:50 PM, Sam P wrote: > Hi All, > > Sending out a gen

[openstack-dev] [openstack-infra][stable][urgent][rally] Someone deleted Rally stable branch, we need to restore

Hi, Someone somehow deleted 0.9.* branches from GitHub repo https://github.com/openstack/rally A lot of end users are using these branches and are affected by this change. Can someone help to restore them? Best regards, Boris Pavlovic

Re: [openstack-dev] [Tripleo] Containerizing tempest

Chandan, Not a big expert in Kola, but I have the same task for containerizing Rally. The solution is simple, just use ENTRYPOINT like here: https://github.com/openstack/rally/blob/master/Dockerfile#L38 (but for tempest) Best regards, Boris Pavlovic On Mon, Oct 9, 2017 at 10:08 PM, Chandan

Re: [openstack-dev] [ptg] Simplification in OpenStack

Jay, OK, I'll bite. This doesn't sound like a constructive discussion. Bye Bye. Best regards, Boris Pavlovic On Thu, Sep 14, 2017 at 8:50 AM, Jay Pipes wrote: > OK, I'll bite. > > On 09/13/2017 08:56 PM, Boris Pavlovic wrote: > >> Jay, >> >> All

Re: [openstack-dev] [ptg] Simplification in OpenStack

ogramming language, so it's sort of big type mismatch and logically wrong. However, what's wrong with Cobol? If you use right architecture and right algorithms it will definitely work better than implementation of program in any other language with wrong architecture and bad algorithms... so n

Re: [openstack-dev] [ptg] Simplification in OpenStack

standard and easy way to upgrade So basically we are not losing anything even if we do not backward compatible changes and rethink completely architecture and API. I know this sounds like science fiction, but I believe community will appreciate steps in this direction... Best regards, Boris Pavlo

Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

/implementation/hook_and_trigger_plugins.html Best regards, Boris Pavlovic On Mon, Aug 14, 2017 at 2:35 AM, Sam P wrote: > Hi All, > > This is a follow up for OpenStack Extreme Testing session[1] > we did in MEX-ops-meetup. > > Quick intro for those who were not there: > In t

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

it won't help community too much to fix the real problems in architecture (in my opinion it's too late), for example creating VM performs ~400 DB requests... and yep this is going to be slow, and now what? how can you fix that?.. Best regards, Boris Pavlovic On Fri, Aug 4, 2017 at 1:12 P

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

s interface in such way that it's easy to extend and provide to end user nice user experience from both side (shell & python) and nice and stable interface for client developers . By the way stevedore is really providing very bad plugin experience and should not be used definitely. Best r

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

Rajul, May I ask why you think so? Exposed by OSprofiler issues are going to be really hard to fix in current OpenStack architecture. Best regards, Boris Pavlovic On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar wrote: > Hi Boris > > Good to hear from you. > May I ask why you thin

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

Rajul, It makes sense! However, maybe it's a bit too late... ;) Best regards, Boris Pavlovic On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar wrote: > Hello everyone > > I have added a blueprint on having tail-based sampling as a sampling > option for continuous tracing in OSProf

[openstack-dev] [glance][rally] Disabling Glance Testing in Rally gates

/1fa653635781cd975a1031e212b35b6c38196ba4 Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

roperly git review 3) Maybe few tutorials (how to find some bug, how to test it and where are the docs, devstack, ...) That would simplify onboarding process... Best regards, Boris Pavlovic On Mon, Jun 26, 2017 at 2:45 AM, Alexandra Settle wrote: > I think this is a good idea :) thanks Mike.

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

resource information and doing this very very simple and easy placement selection... Best regards, Boris Pavlovic On Mon, Jun 19, 2017 at 5:05 PM, Edward Leafe wrote: > On Jun 19, 2017, at 5:27 PM, Jay Pipes wrote: > > > It was from the straw man example. Replacing the $FOO_UUID wi

[openstack-dev] [rally][no-admin] Finally Rally can be run without admin user

#x27;t be able to use plugins that requires admin role. This patch finishes works: https://review.openstack.org/#/c/465495/ Thanks to everybody that was involved in this huge effort! Best regards, Boris Pavlovic __ OpenSta

Re: [openstack-dev] [tc] Active or passive role with our database layer

way to align everybody in community and make it default for all projects. Best regards, Boris Pavlovic On Tue, May 23, 2017 at 2:18 PM, Zane Bitter wrote: > On 21/05/17 15:38, Monty Taylor wrote: > >> One might argue that HA strategies are an operator concern, but in >> r

[openstack-dev] [rally] Project Update Slides (Pika)

Hi stackers, Here are the slides from summit https://docs.google.com/presentation/d/1QxsQh8E7Tr46KkLPV7QTwBAbTKFtB6dVEv-pQwg6LUA/edit#slide=id.p4 Here is the video https://www.openstack.org/videos/boston-2017/project-update-rally Best regards, Boris Pavlovic

Re: [openstack-dev] [tripleo] pingtest vs tempest

most of the functionality. If you specify what exactly you want to test I can help with writing Rally Task for that. (it will use as minimum as possible resources) Best regards, Boris Pavlovic On Thu, Apr 6, 2017 at 2:38 AM, Dmitry Tantsur wrote: > On 04/05/2017 10:49 PM, Emilien Macchi wrot

Re: [openstack-dev] [Rally] Open HTML Task report in other machine

HTML report (which makes it work without internet) Best regards, Boris Pavlovic On Fri, Mar 24, 2017 at 6:27 AM, Fernando López wrote: > Dear all, > > I just started to play with Rally and I wonder if I could get the output > html file with the results of a executed task and o

Re: [openstack-dev] OpenStack New Years Resolutions

Jean-Philippe, > s/COBOL/go/g and it makes your comment even funnier. It makes it scary =) Best regards, Boris Pavlovic On Tue, Dec 13, 2016 at 2:24 AM, Jean-Philippe Evrard < jean-philippe.evr...@rackspace.co.uk> wrote: > s/COBOL/go/g and it makes your comment even funni

Re: [openstack-dev] [Openstack-operators] Destructive / HA / fail-over scenarios

plemented as a single Rally task which is quite convenient. Best regards, Boris Pavlovic On Wed, Nov 30, 2016 at 6:02 AM, Dulko, Michal wrote: > On Mon, 2016-11-28 at 15:51 +0300, Timur Nurlygayanov wrote: > > Hi OpenStack developers and operators, > > > > we are going to cr

Re: [openstack-dev] Cloud Reliability and Resilience for OpenStack (Fault Injection, Chaos Engineering, and Google SRE)

github.com/openstack/rally/blob/master/doc/specs/in-progress/hook_section.rst You are very welcome to join this effort and help Rally team deliver it faster. Thanks! Best regards, Boris Pavlovic On Wed, Aug 31, 2016 at 11:55 PM, Jorge Cardoso (Cloud Operations and Analytics, IT R&D Divisio

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

to rally, I would like to see feature > parity comparison. It's very necessary to understand how much work we need > to spend to rewrite all our tests in rally way. Totally agree, let's do it. Best regards, Boris Pavlovic On Mon, Jun 27, 2016 at 8:58 AM, Vladimir Kuklin wro

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

e of performance. By the way, Rally stores all results to DB (it stored it always) and is know capable to build performance trends of many runs Best regards, Boris Pavlovic > > > > > On Fri, Jun 10, 2016 at 3:58 PM, Morgan Fainberg wrote: > > > On Fri, Jun 10, 201

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

Lance, I share just how it looked from my side. I really support your idea (no matter what you pick to use your tooling/rally/jmeter) it is very valuable, especially if it will become voting job. This really should be done by someone. Best regards, Boris Pavlovic On Fri, Jun 10, 2016 at 3:26

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

so we are blind and can't see where is the issue in code 5. They didn't help to develop any Rally plugin or even review the Rally test cases that we proposed to them Best regards, Boris Pavlovic On Mon, Jun 6, 2016 at 10:45 AM, Clint Byrum wrote: > Excerpts from Brant Knu

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

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 wi

Re: [openstack-dev] [Rally] Could you share reference for Mitaka Upadates

Yuki, Sorry for long reply. Here are the slides: https://docs.google.com/presentation/d/1g5fd2BJXc40yienjCB0Fuc8NaB0e5pQO0XbUHQ1CY0s Best regards, Boris Pavlovic On Tue, May 10, 2016 at 12:16 AM, Yuki Nisiwaki wrote: > To: Mr. Boris > cc: OpenStacker who is interested in Rally > >

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

Great! On Wed, Apr 13, 2016 at 2:56 PM, Sylvain Bauza wrote: > > > Le 13/04/2016 19:53, Matt Riedemann a écrit : > >> I'd like to propose that we make Andrey Kurilin core on python-novaclient. >> >> He's been doing a lot of the maintenance the last several months and a >> lot of times is the fir

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

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(trainin

[openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

for large clouds. Thoughts? [1] http://web.mit.edu/kerberos/ [2] http://ldapcon.org/2011/downloads/hummel-slides.pdf Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe

[openstack-dev] [python-openstackclient] I tried it and....

Hi stackers, Recently I tried openstackclient and it has amazing UX! Thanks to everybody involved in this! You are doing great job keep going! Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [Tempest] [Devstack] Where to keep tempest configuration?

, devops, devs,...) Best regards, Boris Pavlovic On Thu, Mar 17, 2016 at 4:50 AM, Jordan Pittier wrote: > > > On Thu, Mar 17, 2016 at 12:24 PM, Vasyl Saienko > wrote: > >> Hello Community, >> >> We started using tempest/devstack plugins. They allows to do

Re: [openstack-dev] [all][infra] revert new gerrit

Hi everybody, What about if we just create new project for alternative Gerrit WebUI and use it? I don't think that with current set of web frameworks it would be too hard. Best regards, Boris Pavlovic On Fri, Mar 18, 2016 at 9:50 AM, Andrew Laski wrote: > > > > On Fri, Mar 1

Re: [openstack-dev] [cross-project] [all] Quotas -- service vs. library

s lib that requires db migrations, we will need to run amount of projects migrations. Best regards, Boris Pavlovic On Tue, Mar 15, 2016 at 11:25 PM, Nikhil Komawar wrote: > Hello everyone, > > tl;dr; > I'm writing to request some feedback on whether the cross project Quotas &g

[openstack-dev] [Rally] PTL candidacy

export results functionality (CLI and plugins for many systems) - Disaster cleanup (be able to cleanup env no matter what happened) - many other interesting tasks Best regards, Boris Pavlovic __ OpenStack Development Mailing List

Re: [openstack-dev] [oslo] Common RPC Message Trace Mechanism

Xuanzhou, I am not sure what do you mean by "trace". But if you need something that allows to do cross service/project tracing then you should take a look at osprofiler: https://github.com/openstack/osprofiler Best regards, Boris Pavlovic On Sun, Mar 6, 2016 at 8:15 PM, Xuanzhou

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

Hi, It's still not clear for me, why we can't just add Rally jobs with scenarios related to specific project. It will work quite fast and it will cover CLI (instantly) with good integration/functional testing. Best regards, Boris Pavlovic On Wed, Mar 2, 2016 at 4:52 AM, Sean Da

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

can't give guarantee that we are facing 100% of cases (however facing most of issues is better then nothing) Best regards, Boris Pavlovic On Wed, Mar 2, 2016 at 7:30 AM, Michał Dulko wrote: > On 03/02/2016 04:11 PM, Gorka Eguileor wrote: > > On 02/03, Ivan Kolodyazh

Re: [openstack-dev] [mitaka][hackathon] Mitaka Bug Smash Hackathon in Bay Area (March 7-9)

Just making sure that everybody saw this topic. Best regards, Boris Pavlovic On Thu, Feb 11, 2016 at 11:21 AM, Boris Pavlovic wrote: > Hi stackers, > > If you are in Bay Area and you would to work together with your friends > from community on fixing non trivial bugs together, you

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

(which is actually quite simple task after those change) and moving that code outside of Nova. So solutions are quite similar overall. I hope you'll get more luck with getting them in upstream. Best regards, Boris Pavlovic On Sun, Feb 14, 2016 at 11:08 PM, Cheng, Yingxin wrote: > Thanks Bo

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Yingxin, This looks quite similar to the work of this bp: https://blueprints.launchpad.net/nova/+spec/no-db-scheduler It's really nice that somebody is still trying to push scheduler refactoring in this way. Thanks. Best regards, Boris Pavlovic On Sun, Feb 14, 2016 at 9:21 PM, Cheng, Yi

[openstack-dev] [mitaka][hackathon] Mitaka Bug Smash Hackathon in Bay Area (March 7-9)

s well, please provide here info in which project you are interested: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-BayArea Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [keystone][neutron][requirements] - keystonemiddleware-4.1.0 performance regression

Hi, By the way OSprofiler trace shows how this regression impacts on amount of DB queries done by Keystone (during the boot of VM): http://boris-42.github.io/b2.html Best regards, Boris Pavlovic On Wed, Jan 20, 2016 at 3:30 PM, Morgan Fainberg wrote: > As promised here are the fi

Re: [openstack-dev] [Oslo][all] os-profiler under Oslo umbrella

Dims, Great news! =) When we address some small issues I'll make demo. Best regards, Boris Pavlovic On Wed, Jan 13, 2016 at 5:06 AM, Davanum Srinivas wrote: > Team, > > Oslo folks have voted[1] to be the home for the osprofiler project[2]. > Several projects are already usin

[openstack-dev] [oslo][osprofiler] OSprofiler spec is ready for review

Hi stackers, OSprofiler spec is ready for review. Please review it, if you are interested in making native profiling/tracing OpenStack happen: https://review.openstack.org/#/c/103825/ Thanks! Best regards, Boris Pavlovic

Re: [openstack-dev] [Neutron][QA] New testing guidelines

Assaf, We can as well add Rally testing for scale/performance/regression testing. Best regards, Boris Pavlovic On Wed, Dec 16, 2015 at 7:00 AM, Fawad Khaliq wrote: > Very useful information. Thanks, Assaf. > > Fawad Khaliq > > > On Thu, Dec 10, 2015 at 6:26 AM, Assaf Muller

Re: [openstack-dev] [Kuryr] Testing, Rally and Wiki

is. What this context is going to do? Best regards, Boris Pavlovic On Thu, Dec 10, 2015 at 6:11 AM, Gal Sagie wrote: > Hello everyone, > > As some of you have already noticed one of the top priorities for Kuryr > this cycle is to get > our CI and gate testing done. > > I ha

Re: [openstack-dev] [Fuel] [QA] [Tests] MOS integration tests in SWARM test suite

Timur, I hope you are going to use for [1] and [2] Rally verify command? Best regards, Boris Pavlovic On Mon, Dec 7, 2015 at 6:09 AM, Timur Nurlygayanov < tnurlygaya...@mirantis.com> wrote: > Hi Fuel team, > > we have a lot of automated integration tests for OpenStack verifi

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

+1 from me On Fri, Dec 4, 2015 at 8:16 AM, Joshua Harlow wrote: > +1 from me :) > > Dina Belova wrote: > >> Dear performance folks, >> >> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays >> ) to >> 16:00 U

Re: [openstack-dev] Rally as A Service?

Obed, We are refactoring Rally to make it possible to run it as a deamon. There is plenty amount of work that should be done, including this spec: https://review.openstack.org/#/c/182245/ Best regards, Boris Pavlovic On Tue, Nov 24, 2015 at 2:20 PM, Munoz, Obed N wrote: > > -- > Obe

Re: [openstack-dev] [tc][all][osprofiler] OSprofiler is dead, long live OSprofiler

Hi stackers, I updated OSprofiler spec: https://review.openstack.org/#/c/103825/ reviews are required. Best regards, Boris Pavlovic On Mon, Nov 9, 2015 at 2:57 AM, Boris Pavlovic wrote: > Hi stackers, > > Intro > --- > > It's not a big secret that OpenStack

[openstack-dev] [tc][all][osprofiler] OSprofiler is dead, long live OSprofiler

he way somebody would like to join this effort?) Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://l

Re: [openstack-dev] Questions regarding OpenStack CI tools

Hi Maty, Usually in python projects are used next thing: - cover - for unit test coverage - pep8 + custom hacking rules - to check code styles - pylint - to check even more code styles Best regards, Boris Pavlovic On Sun, Nov 8, 2015 at 4:41 AM, GROSZ, Maty (Maty) < maty.gr...@alca

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

se it doesn't seem like hard task to collect the numbers. Best regards, Boris Pavlovic On Thu, Nov 5, 2015 at 3:56 AM, Robert Collins wrote: > On 5 November 2015 at 04:42, Sean Dague wrote: > > On 11/04/2015 10:13 AM, John Garbutt wrote: > > > I think longer term we pro

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

t..) Best regards, Boris Pavlovic On Thu, Nov 5, 2015 at 12:42 AM, Sean Dague wrote: > On 11/04/2015 10:13 AM, John Garbutt wrote: > > On 4 November 2015 at 14:49, Jay Pipes wrote: > >> On 11/04/2015 09:32 AM, Sean Dague wrote: > >>> > >>> On 11/04/2015 09

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

that we have to have Async API, because we have long running operations. And basically there are 3 approaches to understand that operation is done: 1) pub/sub 2) polling resource status 3) long polling requests All approaches have pros and cons, however the "actual" problem will stay t

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

nfo: http://paste.openstack.org/show/477934/ (it has 6 joins) This is how it looks for glance image: http://paste.openstack.org/show/477933/ (it has 2 joins) So the performance/scale impact will be higher. Best regards, Boris Pavlovic On Wed, Nov 4, 2015 at 4:18 PM, Clint Byrum wrote: > Ex

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

upporting both approaches? Best regards, Boris Pavlovic On Wed, Nov 4, 2015 at 9:33 AM, Morgan Fainberg wrote: > > On Nov 3, 2015 4:29 PM, "Clint Byrum" wrote: > > > > Excerpts from Boris Pavlovic's message of 2015-11-03 14:20:10 -0800: > > > Hi st

[openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

tains multiple JOINs, e,g for nova vm it's 6 joins). What if we add new API method that will just resturn resource status by UUID? Or even just extend get request with the new argument that returns only status? Thoughts? Best regards, Boris Pavlovic __

Re: [openstack-dev] Scheduler proposal

evelopment which is good. Best regards, Boris Pavlovic On Sun, Oct 11, 2015 at 12:23 AM, Clint Byrum wrote: > Excerpts from Boris Pavlovic's message of 2015-10-11 00:02:39 -0700: > > 2Everybody, > > > > Just curios why we need such complexity. > > > > > >

Re: [openstack-dev] Scheduler proposal

nly about his AZ, and separated AZ can have own rabbit servers for example which will allows us to get horizontal scalability in terms of AZ. So do we really need Cassandra, Mongo, ... and other Web-scale solution for such simple task? Best regards, Boris Pavlovic On Sat, Oct 10, 2015 at 11:19 P

Re: [openstack-dev] [OPNFV] [Functest] Tempest & Rally

Jose, Rally community provides official docker images here: https://hub.docker.com/r/rallyforge/rally/ So I would suggest to use them. Best regards, Boris Pavlovic On Fri, Sep 25, 2015 at 5:07 AM, Jose Lausuch wrote: > Hi, > > > > Thanks for the hint Boris. > > > &

Re: [openstack-dev] [OPNFV] [Functest] Tempest & Rally

Morgan, You should add at least: sla: failure_rate: max: 0 Otherwise rally will pass 100% no matter what is happening. Best regards, Boris Pavlovic On Thu, Sep 24, 2015 at 10:29 PM, Tikkanen, Viktor (Nokia - FI/Espoo) < viktor.tikka...@nokia.com> wrote: > Hi Morgan > >

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

ch 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

Re: [openstack-dev] [openstack-operators][tc][tags] Rally tags

Thierry, Okay great I will propose patches. Best regards, Boris Pavlovic On Mon, Sep 21, 2015 at 1:14 AM, Thierry Carrez wrote: > Boris Pavlovic wrote: > > I have few ideas about the rally tags: > > > > - covered-by-rally > >It means that there are official (ins

[openstack-dev] [rally][releases] New Rally release model

xes and part of features to it *) Stable version - we will port only high & critical bug fixes if it is possible Here is the diagram that explains the release cycle: [image: Inline image 1] Thoughts? Best regards, Boris P

[openstack-dev] [openstack-operators][tc][tags] Rally tags

.openstack.org/#/c/225176/5 which will be the standard way to check whatever cloud is ready for production based on volume, performance & scale testing. Thoughts? Best regards, Boris Pavlovic __ OpenStack Developme

[openstack-dev] [Rally] PTL candidacy

s I would like to continue to work as PTL of Rally until we get all this done. Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack

Re: [openstack-dev] [requirements] dependencies problem on different release

e must be many packages are installed as > upstream versions and some of them breaks. An ugly way is to copy pip list > from old Juno environment and install those properly. I hope there are > better ways to do this work. Anyone has smart ideas? Install everything in virtualenv (or at least Rall

Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs

Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko wrote: > Hi folks! > > Today I’m proud to announce that since this moment python-fuelclient has > it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me &

Re: [openstack-dev] [rally] [Ceilometer] profiler sample resource id

Pradeep, Actually this topic is more about osprofiler & ceilometer. Overall it doesn't require this prefix. However it is used in osproifler lib. https://github.com/stackforge/osprofiler/blob/master/osprofiler/parsers/ceilometer.py#L129 Best regards, Boris Pavlovic On Thu, Aug 13,

Re: [openstack-dev] [fuel] Plan to implement the OpenStack Testing Interface for Fuel

adding openstack-ci jobs. -1 risk. Best regards, Boris Pavlovic On Sat, Jul 18, 2015 at 12:16 AM, Dmitry Borodaenko < dborodae...@mirantis.com> wrote: > One of the requirements for all OpenStack projects is to use the same > Testing > Interface [0]. In response to the Fuel appli

Re: [openstack-dev] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?

nes will be less or the same (if everything was covered before) Fixing typos in docstrings won't introduce new lines. Btw job allows you to introduce N (few) new lines that are not covered by unit tests that are uncovered in some cases. Best regards, Boris Pavlovic On Thu, Jul 2, 2015 at

Re: [openstack-dev] stackforge projects are not second class citizens

rrently. We have about 130 (40 at the begging on kilo) patches on review. *) In IRC +15 online members in average *) We merged about x2 if we compare to kilo-1 vs liberty-1 *) I see a lot of interest from various companies to use Rally (because it is *official* now) Best regards, Boris Pavlovic

Re: [openstack-dev] [Neutron] Issue with pymysql

Sean, Thanks for quick fix/revert https://review.openstack.org/#/c/191010/ This unblocked Rally gates... Best regards, Boris Pavlovic On Fri, Jun 12, 2015 at 8:56 PM, Clint Byrum wrote: > Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700: > > > > On 6/12/15

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

Dmitry, We introduced recently dsvm rally ironic job: https://review.openstack.org/#/c/187997/ Now we are working on Rally tests for Ironic: https://review.openstack.org/#/c/186064/ Don't hesitate to join us=) Best regards, Boris Pavlovic On Wed, Jun 10, 2015 at 1:23 PM, Dmitry Tantsur

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

, scalability, load...) so you are killing two birds with one stone. P.S. I would imho prefer to keep all high quality plugins inside Rally repo to simplify operators life.. Best regards, Boris Pavlovic On Wed, Jun 10, 2015 at 11:57 AM, Ken'ichi Ohmichi wrote: > 2015-06-10 16:48 GMT+09:00 Dmitry

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Hi, Maybe we should just give a try: 1) I will prepare all modifications out of infra and show demo 2) Get it in Infra as experimental feature 3) Try it in Rally 4) Share experience and if it is worth keep it or get rid of it. Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 9:21 PM

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

using improper words.. Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 9:05 PM, Nikola Đipanov wrote: > On 06/05/2015 06:31 PM, Doug Hellmann wrote: > > Excerpts from Boris Pavlovic's message of 2015-06-05 20:03:44 +0300: > >> Hi stackers, > >> > >&g

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

any reason for that? Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 8:43 PM, Sylvain Bauza wrote: > > > Le 05/06/2015 19:03, Boris Pavlovic a écrit : > > Hi stackers, > > Seems likes after stackforge/rally -> openstack/rally Rally project > started being mor

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

g such list. Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 8:31 PM, Doug Hellmann wrote: > Excerpts from Boris Pavlovic's message of 2015-06-05 20:03:44 +0300: > > Hi stackers, > > > > Seems likes after stackforge/rally -> openstack/rally Rally project

[openstack-dev] [rally][scaling up development] Rally core team re-organization

thing else I hope by end of this cycle each component will have own subteam which will resolve most of reviewing process scale issues.. Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage question

Re: [openstack-dev] [puppet] Change abandonment policy

Hi, +1 for #1 and if patch is not touched for N weeks just finish it using current active team. Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 7:27 PM, Richard Raseley wrote: > Colleen Murphy wrote: > >> 3) Manually abandon after N months/weeks changes that have a -1 that

Re: [openstack-dev] [all]Big Tent Mode within respective projects

uld clean up, stabilize and > document the virt driver API in Nova before any splitting of driver repos > would be feasible. Imho not only Neutron has this. ;) Rally support out of tree plugins as well and I saw already some third party repos: https://github.com/stackforge/haos Best regards,

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Josh, Yep let's just make experiment in Rally and I will share experience with the rest of community. Best regards, Boris Pavlovic On Wed, Jun 3, 2015 at 9:45 PM, Joshua Harlow wrote: > S, just some thoughts, > > If boris thinks this might help rally, why not just let him

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

oc, releases, management, code review, ...). Splitting to repos really impact on architecture a lot. Best regards, Boris Pavlovic ​ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-d

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

James B. One more time. Everybody makes mistakes and it's perfectly OK. I don't want to punish anybody and my goal is to make system that catch most of them (human mistakes) no matter how it is complicated. Best regards, Boris Pavlovic On Wed, Jun 3, 2015 at 5:33 PM, James

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

are quite different and usually isolated communities. Plugins are not so hard to review and mostly developed part. If I would be able to have cores for specific areas that will scale up code reviewing process a lot without any trust, process, social, arch, whatever changes in project. Best regards

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

h has never build something > awesome. I don't believe even my self, because I am human and I make mistakes. My goal on the PTL position is to make such process that stops "human" mistakes before they land in master. In other words everything should be automated and pre not post

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

omate this stuff. Like we have automated CI for testing. Best regards, Boris Pavlovic On Wed, Jun 3, 2015 at 2:28 PM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/03/2015 08:29 AM, Boris Pavlovic wrote: > > Guys, > > > > I will try

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

ganized. Best regards, Boris Pavlovic On Wed, Jun 3, 2015 at 12:55 PM, Alexis Lee wrote: > Robert Collins said on Wed, Jun 03, 2015 at 11:12:35AM +1200: > > So I'd like us to really get our heads around the idea that folk are > > able to make promises ('I wil

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

's why we have blocking CI system that checks patches, That's why we have rule 2 cores / review (sometimes even 3,4,5...)... In ideal work Lieutenants model will work out of the box. In real life all checks like: person X today has permission to do Y operation should be checked automatical

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Especially if we are speaking about various groups of cores that are mantaining only parts of systems. Keeping all this in heads will be hard task (it should be automated) Best regards, Boris Pavlovic On Wed, Jun 3, 2015 at 2:12 AM, Robert Collins wrote: > On 3 June 2015 at 10:34, Jeremy Sta

[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

People from such ACL group will be able to merge changes that touch only files from some specific subdirs. As a result with proper organization of directories in project we can scale up review process without losing quality. *Though

[openstack-dev] [rally][summit] Rally summit updates

Hi stackers, For those who don't want to miss anything related to Rally on summit I make a small blogpost that covers most interesting things: http://boris-42.me/rally-on-openstack-summit-in-vancouver/ Best regards, Boris Pav

Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests

other project=( and not just use it. Best regards, Boris Pavlovic On Thu, May 14, 2015 at 11:45 PM, Robert Collins wrote: > On 15 May 2015 at 08:34, Jay Pipes wrote: > > > > Hi Maish, > > > > I would support this kind of thing for projects that wish to do it, but &g

Re: [openstack-dev] [openstack-operators][Rally][announce] What's new in Rally v0.0.4

Mike, Thank you for release notes! Nice work! Best regards, Boris Pavlovic On Thu, May 14, 2015 at 5:48 PM, Mikhail Dubov wrote: > Hi everyone, > > Rally team is happy to announce that we have just cut the new release > 0.0.4! > > *Release stats:* > >- Commits: *8

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

Mike, Thank you for saying all that you said above. Best regards, Boris Pavlovic On Tue, May 12, 2015 at 2:35 AM, Clint Byrum wrote: > Excerpts from Mike Bayer's message of 2015-05-11 15:44:30 -0700: > > > > On 5/11/15 5:25 PM, Robert Collins wrote: > > > > &g

  1   2   3   4   >