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