17:04:40 #startmeeting rally 17:04:40 Meeting started Tue Feb 17 17:04:40 2015 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:04:44 The meeting name has been set to 'rally' 17:04:47 to many meeting on one day lol 17:05:15 boris-42, it's awful 17:05:49 boris-42 cheer up! 17:05:55 hi 17:05:58 Hi guys 17:06:03 meteorfox: hey hey 17:06:17 hi 17:06:20 hi 17:06:38 so let's disucss the topic of persistance context 17:06:59 as far as meteorfox is interested in it 17:07:24 meteorfox: this is our roadmap https://docs.google.com/a/mirantis.com/spreadsheets/d/16DXpfbqvlzMFaqaXAcJsBzzpowb_XpymaK2aFY2gA2g/edit?usp=drive_web 17:07:46 boris-42: thanks 17:08:28 meteorfox: 24 point is related to persistance context 17:08:37 meteorfox: so the idea is to do next 17:08:48 meteorfox: have command rally context 17:08:52 boris-42: awesome 17:09:05 meteorfox: that will accept deployment uuid (and context section as now) 17:09:18 meteorfox: and just create context that you speicfy (so run only setup() part) 17:10:02 boris-42: sounds promising 17:10:33 meteorfox: and then there will be special context (use_persistance_context: uuid/name) 17:10:57 meteorfox: that you are specifinig for each test 17:11:14 meteorfox: so the issue that we have are next 17:11:18 right 17:11:23 1) improving cleanup (to make them separated) 17:11:57 2) adding some validation stuff (to check that you can actually use persistance context and context that you specify together) 17:12:05 first is in progress 17:12:11 another will take some amount of time 17:12:58 meteorfox: btw as far as you are in meeting 17:13:06 meteorfox: do you have something to share from operators side? 17:13:08 like this stuff? 17:13:35 boris-42: ok, quick questions, perhaps I'm missing some important part, but wouldn't the persistance context create a given context, and every time you run a new task, first validate that such conditions are met, then run the scenario? 17:13:58 then have another rally context command that can 'unapply the perstiance context 17:14:12 meteorfox: yep it's all in rally context 17:14:25 meteorfox: you will have rally context list / delete / create / show 17:14:26 commands 17:14:38 ok sounds reasonable 17:15:26 meteorfox: so any other thoughts?) 17:15:57 well, for the sake of the others, I work at Rackspace, currently looking at performance test our private cloud offering with Rally 17:16:37 we decided to go with the community with this one, and contribute to Rally, instead of re-inventing the wheel 17:16:59 meteorfox: nice =) 17:16:59 also, we are very interested in the CI gating integration w SLA 17:17:31 meteorfox: btw I would like to start work on cloud validation stuff 17:17:41 meteorfox: like huge parametrized rally task that will check everything 17:18:22 meteorfox: I think it should be interesting for you as well. I will make blogpost related to this topic and send to mailing list 17:18:23 boris-42: you mean everything that was specified in the persistence context, right? 17:18:35 meteorfox: nope it's not related to persistance context 17:18:47 meteorfox: checking that everything works in openstack 17:18:54 oh 17:19:18 wouldn't that be outside of the responabilities of Rally? 17:19:34 meteorfox: so my thoughts are next 17:20:00 meteorfox: keeping this task inside the rally will allow operators from various companies to collabarate together 17:20:41 boris-42: I see your point, but what would constitute a valid deployment? 17:21:15 meteorfox: what we write in that task. We will specify the load and amount of iterations and SLA criterias based on various parameters 17:21:30 meteorfox: amount of controllers, computes, (swift or ceph) and so on 17:21:51 meteorfox: if you can run it and it pass => your cloud works well =) 17:22:55 boris-42: ok, I see what you mean. But this will be highly dependent on how it is deployed, and the hardware used. Maybe have a learning mechanism, that takes a baseline? 17:24:10 meteorfox: so this is not thing that can be done for 1 day 17:24:19 meteorfox: it will require a lot of experiments and so on 17:24:26 right 17:24:37 meteorfox: but the result is quite clear simple task that accepts few arguments 17:24:47 meteorfox: and do all stuff=) 17:25:53 I can envison something that will run several measurements on a reference architecture that you will initially have to run (and possible export the results as a json file), and use that as a baseline, when comparing new deployements 17:26:30 meteorfox: so let me write blogpost 17:26:44 meteorfox: that can make it simpler for understanding=) 17:27:19 okay let's move on 17:27:25 that way I can go to a customer, where I just deployed, and say here's the baseline, you can run rally validation test with this argument, and it will compare your deployment to our baseline 17:27:47 meteorfox: so comparing results is differnet topic 17:27:51 boris-42: thanks, let me know when the blog post goes out 17:27:55 boris-42: alright 17:28:01 meteorfox: so step by step=) 17:28:15 #topic cosntant runner refactoring 17:28:25 msdubov: hey how is it?) 17:29:53 boris-42 hey 17:30:31 So let me give a link to the patch: https://review.openstack.org/#/c/155225/ 17:30:55 I have tested it a bit (with the abort() functionality implemented) 17:31:03 and started to provide it with unit tests 17:31:39 I'm also going to move some common code for constant and rps runners to rally.benchmark.runners.utils 17:32:02 And what will be left is to implement timeouts 17:32:32 msdubov: please 17:32:34 So this is WIP now, but I believe I'll post an update of this patch tomorrow 17:32:36 msdubov: don't work on timeouts 17:32:58 boris-42:Okay, let's move step-by-step! 17:32:58 msdubov: just unification with RPS 17:33:05 msdubov: unit tests 17:33:14 boris-42: ok 17:35:49 msdubov: okay I would like to get this done (without timeouts) in 0.0.2 release 17:36:11 Okay let's move to next stuff 17:36:14 #topic HTML reports 17:36:26 amaretskiy: any news related to your big refactoring when it will be ready?) 17:36:34 I'm working on https://review.openstack.org/#/c/146814/ 17:36:43 the job is done, but unit tests 17:37:04 i will submit patch set in our 17:37:12 but unit tests are still incomplete 17:37:24 so WIP mark will be removed tomorrow 17:37:53 amaretskiy: okay great 17:38:08 amaretskiy: I like that amount of code is reduced 17:38:13 andreykurilin_: I like such refactoring lol 17:38:14 yes 17:38:32 destroy! 17:38:34 even with this nice feature the code is reduced 17:38:36 heh:) 17:38:53 but i do not know the final amount of code after unit tests are updated 17:39:04 andreykurilin_: okay 17:39:10 so let's move to next topic 17:39:18 #topic Mirantis Rally CI is voting 17:39:20 i believe we will still have large amount of code removed :) 17:39:39 So as you can see now Rally Mirantis CI put +1/-1 to verified 17:39:47 which is really nice=) 17:39:48 woot=) 17:40:08 meteorfox: btw if you are interested in making Rally third party testing CI 17:40:18 msdubov: for Rackspace 17:40:25 meteorfox: for Rackspace 17:40:35 boris-42: yes, we are 17:40:57 meteorfox: I mean it will be run against every patch in rally 17:41:12 boris-42: that's awesome 17:41:13 meteorfox: so we can ensure that we are not breaking anything related to your specific deployment 17:41:32 meteorfox: so the only thing is that it requires hardware=) 17:42:22 boris-42: I'm thinking in the long-run we can integrate something like that 17:42:38 boris-42: right now, I just want to get numbers :) 17:42:44 meteorfox: sure sure=) 17:42:58 meteorfox: I mean just want to make sure that there is such opportunity 17:43:12 meteorfox: make sure that you know* 17:43:24 okay let's move to next topic 17:43:30 boris-42: I think is possible, but I don't have control of those things 17:43:34 :) 17:43:39 meteorfox: =) nobody has lol 17:43:59 #topic murano benchmarks 17:44:07 rvasilets__: hey hey 17:44:13 rvasilets__: any news? 17:44:30 Hi! 17:45:09 It's ready and you can review it. I have tested it a lot of time on devstack 17:45:56 I have nothing to add to it already=) 17:45:58 eom 17:47:44 rvasilets__: ok 17:47:52 msdubov: amaretskiy you should review it as well ^ 17:48:00 ok 17:48:02 I didn't see too much reviews from you guys on that patch? 17:48:44 boris-42, Yes, I was mostly concerned with other patches recently 17:48:50 will be done :) 17:48:51 boris-42, rvasilets__ Will make a review! 17:49:11 #topic Installing Rally in DevStack in venv 17:49:24 maybe we should install rally in vevn in devstack? 17:49:48 otherwise they may occur dependency issues 17:50:27 andreykurilin_: amaretskiy msdubov ^ 17:51:00 i like venv 17:51:18 boris-42: imo, venv is better than some hacks with checking oslo.* versions 17:51:40 boris-42, amaretskiy, andreykurilin_, Yes, and seems like this isn't going to be difficult 17:53:21 the only thing is that we will need to update read the docs 17:53:33 to tell the users to activate venv 17:54:08 also we should add ability to install rally in venv to install.sh script 17:54:49 andreykurilin_: there is already abbility 17:54:54 andreykurilin_: just pass -v 17:54:57 hm... 17:55:03 intresting:) 17:55:05 andreykurilin_: install_rally.sh -v 17:55:08 andreykurilin_: lol 17:55:09 =) 17:55:32 btw I would like to rename it to --virtual 17:55:37 or --virutal-env 17:55:41 yeah 17:56:14 because -v associated with --verbose 17:56:15 for me 17:56:16 okay 17:56:16 imho --virtual is confusing 17:56:23 --venv or --virtualenv 17:56:28 --venv I think 17:56:39 sounds the best 17:56:50 boris-42:agree 17:56:54 we can support both options --ven and --virtualenv 17:56:58 :) 17:57:10 andreykurilin_: ok 17:57:16 we should end meeting 17:57:20 so thank you guys 17:57:22 :( 17:57:33 andreykurilin_: mreeee meetings? 17:57:40 andreykurilin_: they took our time?) 17:57:54 So guys see you in rally chat 17:58:04 meteorfox: thank you for attempting meeting 17:58:04 ok 17:58:16 #endmeeting