17:00:35 #startmeeting Rally 17:00:36 Meeting started Tue Jun 17 17:00:35 2014 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:40 The meeting name has been set to 'rally' 17:00:48 msdubov hughsaunders marcoemorais1 ping 17:01:14 boris-42: hey 17:01:33 hi all 17:01:39 Hi Rally o/ 17:02:54 so let' just wait a sec 17:02:58 hey 17:04:19 okay let's just start 17:04:30 #topic hackings 17:04:39 Olga made a quite large patch 17:04:58 https://review.openstack.org/#/c/100599/ 17:05:04 I think we should merge it ASAP 17:05:21 Cause it is blocking next patch 17:05:28 https://review.openstack.org/#/c/96833/ 17:05:47 that contains a lot of updates in different projects 17:06:02 Thoughts ? 17:06:19 first patch or second? 17:06:48 k4n0 first & second we need both 17:06:54 without first we are not able to merge second 17:07:12 k4n0 second patch syncs rally requirements with requirements of rest openstack 17:07:24 then we should quickly review first patch 17:08:22 k4n0 yep 17:08:28 hughsaunders marcoemorais1 ^ 17:08:42 guys you are core you should have your opinion on this as well lol 17:09:30 boris-42: yes it is a big patch, need to look through it 17:09:34 Does look like a sizeable patch, will have to have a read 17:09:37 marcoemorais1: snap 17:10:32 hughsaunders msdubov okay good 17:10:45 #topic Keystone V3 support 17:10:56 Ok we find the guy that will help us with this stuff 17:11:00 it's quite tricky 17:11:19 o/ 17:11:24 can i help? 17:11:26 https://review.openstack.org/#/c/100579/ 17:11:35 ^ k4n0 you can help if you review this 17:11:42 ok 17:11:59 So the idea is to create wrapper 17:12:04 on top of keystone client 17:12:14 so we will unify work with keystone for rest of rally 17:12:34 and it will detect automatically what version we are using and use coressponding API 17:12:42 k4n0 hughsaunders marcoemorais ^ thoguths ? 17:13:40 boris-42: interesting seems potentially useful even outside of rally 17:13:53 Is this a problem of deciding which keystone api to use? (https://github.com/openstack/heat/blob/master/heat/common/heat_keystoneclient.py) 17:14:20 k4n0 nope 17:14:36 k4n0 it's problem that in keystone v3 we have projects and in keystone v2 we have tenants 17:14:45 k4n0 they are similar but with different names... 17:15:01 and different api 17:15:20 ok, and what do we need to use? 17:15:43 k4n0: probably need compatibility with both for now 17:16:05 I see, so we need to lazy load the keystone client based on context 17:16:42 k4n0 if we specified in rally to use v3 17:16:54 k4n0 rally should still work+) 17:17:02 k4n0 at this point it doesn't work 17:17:09 I think heat does something similar (https://github.com/openstack/heat/blob/master/heat/common/heat_keystoneclient.py#L541) 17:17:22 You can specify default keystone backend. 17:17:31 k4n0 it's mess 17:17:37 k4n0 and not related to our task 17:17:39 ok 17:17:44 k4n0 I don't need delete_stack_domain_project 17:17:47 -) 17:17:52 I know :) 17:18:08 k4n0 so we will just unify basic operations that we are using 17:18:14 k4n0 that's all 17:18:18 ok 17:18:32 #topic Tempest Improvements 17:18:41 k4n0 could you share with your work and explain to others? 17:19:04 Yes 17:19:19 https://review.openstack.org/#/c/100481 17:19:28 I am removing dependency on subunit2junitxml 17:19:45 And parsing the raw subunit stream given by "testr" to json 17:19:50 basically subunit2json 17:20:36 questions? 17:21:18 https://blueprints.launchpad.net/rally/+spec/tempest-subunit-to-json 17:21:30 k4n0 agree actually with Andreay 17:21:37 k4n0 about location of subunit2json module=) 17:22:00 you want to invoke subunit2json from tool/subunit2json ? 17:22:09 k4n0 nope 17:22:12 I left comment 17:22:21 k4n0 put it deep inside tempest directory 17:22:33 k4n0 only tempest is using it and will use it 17:23:12 ok, so send subunit2json as patch to tempest? or copy it to tempest during installation from rally 17:23:14 ? 17:23:20 no 17:23:26 k4n0 send module 17:23:35 k4n0 move file in patch* 17:23:55 I dont understand 17:24:06 k4n0 file is in rally/subunit2json.py 17:24:16 ok got it 17:24:22 make it in rally/verification/veirifiers/tempst/subunit2json.py 17:24:28 only tempest is (and will use it) 17:24:29 +1 17:24:35 so it shouldn't be on top of everything 17:24:44 if we put everything in root 17:24:47 it will be mess 17:24:48 =) 17:25:03 ack 17:25:29 Ill make this and other change and submit new patch 17:25:38 k4n0 good 17:25:53 this module can be moved to subunit repo as one of subunit-filter :) 17:26:21 andreykurilin btw yes 17:26:47 andreykurilin but unit it is merged in it we will keep it in rally 17:27:05 lifeless ^ we made subunit2json.py 17:27:07 of course 17:27:18 lifeless are you interesting in getting it in subunit? 17:29:12 #topic ready to merge patch =) 17:29:38 boris-42, imo, we need to send a letter to openstack-dev and discuss this filter 17:29:50 https://review.openstack.org/#/c/92873/12 17:30:07 andreykurilin k4n0 somebody of you guys can make this 17:30:15 andreykurilin: Ill send a mail to mailing list openstack-dev 17:30:24 hughsaunders msdubov marcoemorais guys could you take a look at patch above ^ 17:30:32 * hughsaunders looks 17:30:34 #action send mail regarding subunit2json to openstack-dev 17:31:01 k4n0, ok 17:31:29 #action send mail regarding subunit2json to openstack-dev 17:32:10 #topic OpenStack cross service project profiler 17:32:19 Okay guys I finally finished work on osprofiler 17:32:27 great :) 17:32:28 https://github.com/stackforge/osprofiler 17:32:40 ^ There are just read me and small py33 fix left 17:32:47 and I'll cut release 17:33:04 After that I'll start integrating it in upstream 17:33:34 to integrate it in upstream we will need to put a couple of small patches 17:33:45 https://github.com/boris-42/nova/commit/9ebe86bf5b4cc7150251396cfb302dd05e89085d this is sample of nova integration 17:34:00 and this is required in ceilometer https://review.openstack.org/#/c/100239/ 17:34:37 so as all patches are ready there is a bit bureaucracy 17:34:48 about blue prints and specs and so on 17:34:58 waiting for ceilometer patch to merge? 17:35:06 I need to make ceilometer-spec 17:35:15 to get approved this stuff 17:36:15 ok, so we need spec + patch for other projects also 17:36:25 k4n0 yep 17:36:29 k4n0 I will make one template 17:36:34 k4n0 and copy paste it lol 17:36:35 =) 17:36:37 ok 17:36:40 k4n0 but it will take some time 17:36:40 lol 17:36:50 and then there will be patch in rally 17:37:00 that integrates all this stuff so it will work out of box 17:37:00 =) 17:37:07 looking forward 17:37:11 and we will get traces for every iteration 17:37:23 in such format http://pavlovic.me/rally/profiler/ 17:38:11 #topic open discussion 17:38:26 somebody would like to discuss anything ? 17:38:42 boris-42: good work on profiler 17:38:49 Rally release schedule (rpm, deb, pip) 17:39:20 k4n0: need versions before releases 17:39:25 https://blueprints.launchpad.net/rally/+spec/rally-distribution-packages 17:39:26 Yes 17:39:34 We need to discuss how we will version 17:40:21 yep this is good topic for discussion k4n0 17:40:30 when we are going to start versioning crap? 17:40:51 marcoemorais hughsaunders msdubov ^ 17:41:48 I think there should be next topics 17:42:01 boris-42: as you've said previously its a trade off against velocity. We should start versioning when we intend to support the current version for a while, so UI, API, DB etc 17:42:02 are we going to support upgrades? 17:42:30 hughsaunders but we can just avoid supporting of upgrades 17:42:34 till moment X 17:42:35 =) 17:42:49 e.g. 0.*.* is without supporting upgrades 17:43:23 1.*.* will be with support upgrades 17:43:37 I guess so.. we could go with the openstack cadence, release every 6 months, then that gives a time frame to work in 17:43:46 hughsaunders nope 17:43:58 hughsaunders I think it will be better to make short releases 1.5-2weeks 17:44:08 without supporting upgrades 17:44:28 how about going with tempest release cycle? the branchless one 17:44:35 until we will have stable API/UI/DB 17:44:47 k4n0 there is no more branches 17:44:57 k4n0 plus why we need to be aligned with them at all? 17:45:08 k4n0 imho versions should be done depending on changes in Rally 17:45:18 yes, bad idea, :) 17:45:22 just a thought 17:45:32 if we have a lot of changes for 1 week we can make version 17:45:53 if there is no changes we can wait 2 or even more weeks 17:46:08 how do we define "lot of changes" ? 17:46:14 i'll define=) 17:46:20 ok :) 17:46:21 works for me 17:46:27 depending on temperature on Mars 17:46:28 =) 17:46:34 so 17:46:38 about versioning 17:46:40 I am trying to get a rpm built internally in my office 17:47:01 x.x.* should be backward comp. fully 17:47:17 e.g. the same DB can be used with x.x.N and x.xN+K 17:47:31 boris-42: so push a tag to the repo every few weeks? 17:47:39 hughsaunders yep 17:47:59 x.N.* and x.N+1.* are not backward compability 17:48:06 and there is no upgrade for such change 17:48:24 cause I don't want to lose time at this point for upgrades 17:48:46 hughsaunders so actually we will make releases like python clients 17:48:56 hughsaunders they are doing it on demand 17:48:58 k4n0 ^ 17:49:07 ok 17:49:12 +1 17:49:23 when we will be enough stable 17:49:30 when we move to 1.*.* 17:49:36 we will start supporting upgrades 17:50:25 k4n0 hughsaunders so current versioning will be some kind of baby step to the full versioning 17:50:40 got it 17:51:13 boris-42: seems like a good idea, so we get the process going for releasing, but without the stability requirements as its 0.0.x 17:51:16 k4n0 could you put this in blueprint? 17:51:23 hughsaunders yep 17:51:31 boris-42: yes, on it 17:51:55 hughsaunders and when we get stability we will have all process about versioning and other stuff ready 17:52:02 hughsaunders and with good experience 17:52:02 =) 17:52:31 Sounds good 17:52:34 Other topics to dicuss? 17:52:59 nothing from my side 17:53:38 okay let's just finish meeting=) 17:53:44 Glad to see you guys 17:54:14 ok, cya. thanks all 17:54:17 #endmeeting