17:00:33 #startmeeting Rally 17:00:33 Meeting started Tue Apr 28 17:00:33 2015 UTC and is due to finish in 60 minutes. The chair is amaretskiy. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:36 The meeting name has been set to 'rally' 17:00:42 hi all 17:01:48 let's start our meeting 17:03:29 #topic Rally QA week 17:04:28 QA -> as in quality assurance, or questions/answers? 17:04:49 questions/answers week =)) 17:04:49 we have an internal plan for QA week 17:05:10 redixin please say what are your tasks within QA week 17:05:25 my? 17:05:30 yes :) 17:05:46 i should set up fuel job on Mirantis Rally CI, and I have a question 17:05:53 according to the plan that was written by boris-42 17:06:09 what is that question? 17:06:16 rally is refusing to launch task if there no openstack deployment 17:06:39 so we should fix this first 17:06:51 good question 17:07:02 actually I'm working on this problem 17:07:18 o/ 17:07:36 so, is there any progress on using fuel client without openstack cloud? 17:08:02 I believe we are making our next step to using rally as independent benchmarking tool 17:08:31 ok. so i have a fuel deployment, and ready to launch job, but 17:08:35 the only solution for this specific case (I think) is to unbound rally from OpenStack environment 17:08:46 i need to know how to set up rally to launch task vs fuel 17:09:28 so when you done, please give me link to patchset, and I'll make a gate job 17:10:04 yes, I'm working on that and I already have dirty implementation of working fuel client inside scenario 17:10:12 good 17:10:40 but I still haven't unbound rally scenario from deployment 17:10:45 Thi si sin progress 17:10:55 So, let's resume this 17:11:19 wait 17:11:25 there is one more patch 17:11:42 https://review.openstack.org/#/c/175549/ <- 17:12:12 this patch is almost done. there is one small change left 17:12:29 it introduces "jobs manifests" 17:12:59 Great. I will review it tomorrow 17:13:04 thanks 17:13:20 Colleagues, let's review this patch 17:13:59 #link https://review.openstack.org/#/c/175549/ 17:14:07 omg how this chat bot works :0 17:14:12 For QA Week, I also have tasks - they are: 1) implement osclients.register() and 2) work with oanifriev on fuel scenarios (create/delete/list_environments) 17:14:39 amaretskiy: sorry to ask, but what is QA Week? 17:14:45 osclients.register() is for qa week? O_O 17:14:47 amaretskiy: just a link if possible 17:15:25 redixin, yes :) 17:15:25 yfried|prtially_: QA -> questions/answers but I have no idea what does that entails, and why there's a week for that 17:15:37 #link https://review.openstack.org/#/c/177884/ 17:15:56 quality assurance 17:16:10 oh ok 17:16:12 it was a joke about Q&A week 17:16:19 :) 17:16:25 redixin: is it an openstack thing, or a Mirantis thing? 17:16:28 oh lol :) I'm dum like that 17:16:30 dumb 17:16:43 Mirantis 17:16:43 meteorfox: we have internal tasks for this week :) 17:16:53 it should be really a lot people with questions to make a Q&A week 17:17:04 So, let's resume with QA week 17:17:33 redixin: lol haha 17:17:35 we have tasks regarding fuel scenarios and we have a problem related to that - it is not solved yet 17:18:48 Let;s do the following - I will try to find the solution tomorrow, or at least provide the descriptive information for possible solution 17:19:13 rvasilets_ what is your tasks for QA Week ? 17:19:14 amaretskiy: redixin: is there a public place, where these QA tasks are shown 17:19:26 besides here in chat log 17:19:43 Me and mdubov was assigned to do Murano benchmarks 17:20:37 After a few discussion with murano team they understand that Murano has a bug and here is it https://bugs.launchpad.net/murano/+bug/1449545 17:20:37 Launchpad bug 1449545 in murano "Unable to delete environment(timeout)" [Undecided,New] 17:20:37 meteorfox unfortunately the doc has internal access and I do not know sharing policy about it :( 17:20:57 We a almost block before thay fix this problem 17:21:01 eof 17:21:06 meteorfox, looks like no 17:21:25 rvasilets: okay, great 17:21:37 so, on QA week we are just working on our usual patches? 17:22:14 redixin as far as I know we have specific patches to work on this week 17:22:16 fuel scenarios, murano scenarios etc 17:22:21 not "regular" :) 17:22:29 why it is called QA? 17:22:34 redixin just look at the doc 17:23:21 This is the name given by elterman 17:23:34 redixin as far as I know these "QA" patches related to testing improvements :) 17:23:53 amaretskiy: What are 0.4 priorities? 17:23:57 rally is whole related to testing improvements %) 17:24:00 redixin Ido you have access to the doc ? 17:24:17 yes but question is not about it 17:24:19 nvm 17:24:24 okay 17:24:40 any other questions regarding QA week tasks? 17:24:52 Elterman gave edict to all project to improve coverage 17:24:53 no 17:25:11 okay, let's proceed to next topic 17:25:28 #topic Upcoming Rally 0.0.4 release: progress on critical patches 17:25:39 pradeep, there is a google doc somewhere with links 17:26:06 #link https://docs.google.com/document/d/1TX5zpYcTX8AXm-K_h1lzUNVCMvbRgsjUKU-dEYNWLY8/edit 17:26:09 redixin: can't this be tracked via launchpad? 17:26:28 #link https://blueprints.launchpad.net/rally/+spec/important-for-next-release 17:26:36 yfried, our PTL hates launchpad and loves google docs 17:26:52 redixin: All hail our PTL :) 17:27:15 yfried we have blueprint just to mark patches as release-important 17:27:42 So, let's discuss important patches 17:27:44 amaretskiy: ok, are these documented anywhere? this is the first time I see the release doc and the bp 17:28:28 amaretskiy: I suggest a bp for each release, because a single bp would quickly get overcrowded 17:28:51 yfried: we need to discuss this with boris-42 17:28:59 I can not solve this :) 17:29:13 blueprint is here, but no patches 17:29:24 amaretskiy: ok. meanwhile, where are the links published? readthedocs? 17:29:34 irc topic? 17:29:36 so we can track only in google doc at this time 17:29:52 yfried I'm not sure that the link is published 17:30:06 in roadmap at 2nd page 17:30:10 first link 17:30:15 I believe we will discuss this with boris-42 17:30:16 it is 17:30:56 sorry, I just forgotten that 17:30:57 rvasilets_: tnx. it is 17:31:05 of course, road map :) 17:31:13 we should add this topic to agenda to next meeting. we should discuss all this tracking stuff 17:31:28 redixin: +1 was gonna right that 17:32:14 I think upcoming release definitely will be in next meeting agenda :) 17:32:48 amaretskiy: let's move on 17:32:54 #link https://review.openstack.org/#/c/137650/ 17:33:15 rvasilets_ do you know what is the progress on thi spatch 17:34:27 After discussion with murano we understand that context is working right 17:35:12 And there is small suggestion wich I try today/tomorrow to realize 17:35:28 but its nut about logic 17:35:30 eom 17:35:35 *not 17:36:13 okay 17:36:40 this patch is ready for review 17:37:03 colleagues, let's review it! 17:37:36 next patch 17:37:47 #link https://review.openstack.org/#/c/171625/ 17:38:28 rvasilets_ what status for it? 17:39:52 Murano team give me also one suggestion which I have already realized but I have ni submited it yet. Logic is right but I have found bug in Murano 17:40:00 with delete environment 17:40:12 realized -> implemented 17:41:01 and I can continue to work on this scenario only after there will repair Murano 17:41:04 eom 17:41:12 rvasilets_, ok, hope this will be solved soon 17:41:28 next patch 17:42:01 #link https://review.openstack.org/#/c/162418/ 17:42:35 does anybody have news from Antonio Messina regarding this patch? 17:43:00 nope 17:43:04 I hope he will finish his great work, this patch is almost complete 17:43:07 amaretskiy: "Allow installation as unprivileged user" is huge work which changes major chunk. 17:43:44 pradee actually this patch is working and required updates does not seem huge 17:43:46 amaretskiy: I actually don't like this patch. It's making some decision that break current behavior. I really don't think it should be merged as is 17:44:03 amaretskiy: I had issues with this patch on Fedora22 17:44:28 I had issues with this on f20 as well 17:44:37 yfried: this patch definitely should be updated, but it is great in general 17:44:54 yfried: amaretskiy : Q: Why do we need this? 17:44:55 amaretskiy: I've posted my objections. most were ignored 17:45:04 yfried: so we need to be sure it is working on fedora 17:45:04 pradeep: we need this. 17:45:08 DO we have solid use case? 17:45:35 okay, anyway we can not discuss this patch with author for now 17:46:04 pradeep, install different versions of rally in different venvs 17:46:07 pradeep we have use case and we need this patch 17:46:15 pradeep, install rally without root privileges 17:46:22 users must have abilitu to install rally without root access 17:46:25 redixin: let me try 17:46:53 okay, lets proceed to next patch 17:47:27 pradeep: install rally without sudo 17:47:42 I skip pathes of boris-42 since hi is on a vacation 17:47:47 pradeep: are you taking over this patch? 17:48:35 let's move to next topic 17:48:57 #topic Spec on refactoring scenario utils: review and discussion 17:49:03 yfried: i tried without sudo 17:49:10 #link https://review.openstack.org/#/c/172831/ 17:49:15 any way let me re-try. Its been while. 17:49:22 amaretskiy: so about this spec, 17:50:00 colleagues, please review this spec 17:50:04 amaretskiy: I've had conflicting reviews from you and boris, and ambiguous comments from meteorfox 17:50:29 yes, ideas differ :) 17:50:41 apart from you, I've been unable to get more info from boris and meteorfox 17:51:13 lets at least collect all items we agree and all that are not decided 17:51:18 yfried: sorry about that. I'll try to be more clearer with my comments 17:51:38 i believe we agree about creating `services' package 17:51:55 and move shared logic from scenarios utis there 17:51:57 amaretskiy: yeah, but it seems we don't agree about what should be in it :) 17:52:01 is that correct? 17:52:08 yes 17:52:20 next point, that, I believe, we agreed 17:52:31 is path to this package 17:52:54 rally.plugins.services 17:53:00 is that correct? 17:53:17 I think so 17:53:35 so, for example, service for keystone/identity will be rally.plugins.services.identity 17:54:02 amaretskiy: ack 17:54:15 I think we haven't decided yet about services naming - by type (identity) of by name (keystone) 17:54:46 yfried: in my case, what I was referring to 'API versioning', as I understand the spec, one of the things it intends to add, is supporting multiple API versions, but the example included doesn't seem to show how exactly one refers to a specific versions, or how they are handled 17:54:51 amaretskiy: that could be argued on patches 17:54:55 but at least we can submit updates spec with already solved pionts - this spec will be more clear 17:55:02 yes 17:55:17 amaretskiy: will do 17:55:22 the main question (as far as I understood) is atomic actions 17:55:34 meteorfox: you mean how rally will know to use keystoneV2 or V3 17:55:36 ? 17:56:12 amaretskiy: I wonder if this should be blocked until atomicmixin is ready 17:56:13 yfried: right, so when the scenario is being written, how does one use the different versions 17:56:18 solution for versioning is also opened question 17:56:58 meteorfox: so assuming you have a generic operation, the code in common should replace the wrappers 17:57:36 atomic actions is great question, and this question requires boris-42 participation 17:57:48 meteorfox: same way that it is done now 17:57:56 yfried: ok, boris-42 suggested something like this, http://paste.openstack.org/show/210538/ but I'm not convinced I like it. 17:58:17 I propose to submit updated spec with already agreed points so we can proceed a bit easy in discussion 17:58:26 amaretskiy: will do 17:58:38 yfried: thank you 17:58:51 okay, let;s proceed to next topic 17:59:18 #topic Spec on in-tree functional tests: review and discussion (https://review.openstack.org/#/c/166487/) 17:59:20 meteorfox: let's continue this offline. please post clarifications to review 17:59:34 okay 17:59:38 yfried: sure, will do. 17:59:45 * morganfainberg sneaks into the back of the room. 17:59:45 let's go into rally chat 18:00:10 #endmeeting