18:02:36 <sputnik13> #startmeeting cue 18:02:38 <openstack> Meeting started Mon Jun 15 18:02:36 2015 UTC and is due to finish in 60 minutes. The chair is sputnik13. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:41 <openstack> The meeting name has been set to 'cue' 18:02:47 <sputnik13> role call~ 18:03:02 <abitha> here 18:03:03 <dkalleg> 1 18:03:47 <sputnik13> we're missing a couple people 18:04:29 <vipul> o/ 18:04:50 <sputnik13> someone go kick esmute 18:04:53 <sputnik13> :) 18:05:29 <sputnik13> #topic Open Action Items 18:05:33 <sputnik13> #link http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-06-08-18.02.html 18:06:01 <davideagnello> 2 18:06:11 <sputnik13> o/ 18:06:11 <esmute> Hello! 18:06:23 <sputnik13> ok we have quorum, let's get to the agenda 18:06:47 <sputnik13> #info AI #1, davideagnello to follow up on rally job merge 18:06:55 <sputnik13> davideagnello? 18:07:05 <davideagnello> yes, the job is merged 18:07:16 <sputnik13> cool, does it look to be working? 18:07:25 <sputnik13> working as in executing the rally job? 18:07:37 <davideagnello> I don't see it in our patches yet 18:07:47 <sputnik13> that sounds like a no 18:07:56 <vipul> it's an experimental job 18:07:59 <sputnik13> do we need a new patch before it shows up? 18:08:10 <sputnik13> experimental is fine, but shouldn't it show up somewhere? 18:08:12 <esmute> you can run it with 'check experimental' 18:08:16 <vipul> you have to comment 'check experimental' 18:08:18 <sputnik13> ic 18:08:31 <davideagnello> ok 18:08:32 <vipul> i saw Sergey tried to run it on one of my patches 18:08:38 <vipul> but it failed immediately 18:08:42 <davideagnello> I noticed that too but it failed 18:08:47 <sputnik13> that doesn't sound good 18:08:50 <vipul> so it's definitely not set up correctly 18:09:01 <sputnik13> ok, sounds like we need more followup then 18:09:15 <vipul> yea follow up with Sergey or fix the job 18:09:45 <davideagnello> what is Sergey's handle or irc? 18:09:47 <sputnik13> #action davideagnello to follow up on rally job merge, work with Sergey to fix job and ensure it runs on some patches 18:10:06 <sputnik13> #info rally job merged but is failing right away 18:11:06 <sputnik13> ok, next? 18:11:15 <sputnik13> #info vipul and sputnik13 to review https://review.openstack.org/#/c/187620/ and +1 it 18:11:47 <vipul> davideagnello: just ask someone in the rally room 18:12:03 <davideagnello> vipul: ok 18:12:06 <sputnik13> oh this is directly related 18:12:15 <sputnik13> AI#2 18:12:16 <vipul> #done 18:12:20 <sputnik13> yup 18:12:33 <esmute> who is doing this work? 18:12:33 <sputnik13> #info https://review.openstack.org/#/c/187620/ has merged, directly related to AI#1 18:12:35 <esmute> Serget? 18:12:41 * sputnik13 elects esmute 18:12:42 <sputnik13> :) 18:13:14 <davideagnello> sputnik13: merged on June 10th 18:13:18 <esmute> if the rally test is failing during the devstack install, you can look at the integration tests setup 18:13:26 <esmute> i had to do some things to get devstack up and running 18:14:06 <esmute> https://github.com/stackforge/cue/tree/master/tests 18:14:17 <esmute> look at the gate_hook.sh, pre_test_hook.sh 18:14:28 <esmute> these will setup devstack 18:15:10 <sputnik13> davideagnello can you take a look at these and follow up with esmute if you have issues/questions? 18:15:36 <vipul> Yea if there are certain things that we need to do that are unique then Sergey will not know those 18:15:44 <davideagnello> sputnik13: this is related to get the rally job running, correct? 18:15:47 <vipul> we're probably better off fixing the job 18:15:47 <sputnik13> yes 18:15:59 <davideagnello> sputnik13: already noted :) 18:16:03 <sputnik13> ok, good 18:16:12 <sputnik13> vipul the action is to "work with Sergey" so I think we're covered ;) 18:16:21 <sputnik13> next AI? 18:16:41 <sputnik13> #info AI #3 esmute to classify https://bugs.launchpad.net/cue/+bug/1439329 and https://bugs.launchpad.net/cue/+bug/1439330 18:16:43 <openstack> Launchpad bug 1439329 in Cue "Cluster goes to ERROR when creating it with flavor passed by name" [Undecided,New] 18:16:44 <openstack> Launchpad bug 1439330 in Cue "Cannot delete cluster by name" [Undecided,New] 18:17:05 <esmute> sputnik13: i tried to do it but it was grey out for me 18:17:11 <sputnik13> these two issues are still in "Undecided" 18:17:28 <sputnik13> esmute: do you not get the edit button? 18:17:36 <vipul> esmute: you are in cue-drivers 18:17:39 <esmute> ok it is working now 18:17:39 <vipul> should work for you 18:17:50 <esmute> it didnt work last week when i tried.. hmm 18:18:09 <sputnik13> right, when you mentioned that vipul added you to cue-drivers 18:18:15 <vipul> Yep 18:18:16 <esmute> ok.. i just classified them as medium since we can still reference them by their id 18:18:34 <sputnik13> it needs to meet the agreed definition 18:18:45 <vipul> so esmute does nova actually support booting vms by flavor name? 18:18:56 <esmute> it does vipul 18:19:05 <vipul> are you sure it's not a nova-client thing? 18:19:09 <esmute> you can pass in m1-small or something like that as teh flavor 18:19:14 <esmute> ohh hmm 18:19:24 <esmute> could be a nova client thing :p 18:19:33 <sputnik13> esmute: https://wiki.openstack.org/wiki/Bugs 18:19:34 <esmute> i can try the rest API and see 18:20:01 <sputnik13> it's not a bug if it's not a supported feature 18:20:38 <vipul> afaict, the nova api accepts a flavorRef 18:20:42 <vipul> which is.. "The flavor reference for the desired flavor for your server instance. 18:20:42 <vipul> Specify as an ID or full URL." 18:20:45 <esmute> ok.. ill check whether it is a bug or not... ill check the nova api and see if it does support referencing flavor by name 18:20:47 <sputnik13> to me this is more a feature, a minor one but a feature 18:20:54 <vipul> #link http://developer.openstack.org/api-ref-compute-v2.html 18:21:09 <esmute> if its not a bug in cue, then it is a bug in cue-client 18:21:21 <vipul> it's a nice-to-have 18:21:36 <sputnik13> so it's more a wishilist item I think 18:21:57 <esmute> it is.. but dont we want to have nova as our role model for the client? 18:22:43 <vipul> does the openstackclient do this 18:22:46 <esmute> meaning, if nova references flavor by name or delete resources by name, cue client should too 18:22:47 <sputnik13> I think we should definitely have these but a lack of a feature is not a bug, a bug is a failure of a feature 18:23:19 <esmute> So should this be a BP then? 18:23:28 <davideagnello> that makes sense 18:23:34 <sputnik13> no, it doesn't need to be a BP, it's small enough i don't think we need that much formality 18:24:05 <sputnik13> but whether something's a defect vs a feature, we should be consistent 18:24:15 <davideagnello> do we just track it as a "wish list" item? 18:24:17 <esmute> so what do these ticket need to be made correct? 18:24:23 <sputnik13> defect = bug, minor feature = wishlist, major feature => bp 18:24:29 <sputnik13> something like that? 18:24:40 <sputnik13> esmute there's a "wishlist" category 18:24:45 <esmute> yeah i just saw that 18:24:47 <sputnik13> you can classify it as thus 18:24:50 <esmute> ok.. 18:24:55 <sputnik13> just don't leave it "undefined" 18:25:54 <sputnik13> are we good with this AI? 18:26:03 <davideagnello> +1 18:26:03 <esmute> ok.. i just classified it as wishlist 18:26:14 <sputnik13> ok, thanks 18:26:20 <sputnik13> #info AI #4 sputnik13 to harass josh barry to classify https://bugs.launchpad.net/cue/+bug/1450931 18:26:21 <openstack> Launchpad bug 1450931 in Cue "Readme doc link incorrect" [Undecided,New] 18:26:47 <sputnik13> I dropped the ball on that, I will get it reclassified and close the loop with Josh 18:27:13 <sputnik13> #action sputnik13 to classify https://bugs.launchpad.net/cue/+bug/1450931 and talk with Josh about classifying submitted bugs 18:27:33 <sputnik13> #info AI #4 sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka 18:27:57 <sputnik13> this one has not started yet, I will be working on it this week and should have more information next week 18:28:05 <sputnik13> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka 18:28:23 <sputnik13> ugh I'm messing up the numbers :( 18:28:27 <sputnik13> that was AI #5 not 4 18:28:47 <sputnik13> wish there was a meetbot feature for referring to AIs for closure 18:28:58 <sputnik13> #info AI #6 davideagnello to add detail to https://blueprints.launchpad.net/cue/+spec/rally-scenario-tests based on existing rally tests and gate testing things in process 18:29:13 <sputnik13> davideagnello did you have a chance to close this out? 18:29:47 <sputnik13> I don't see any updates to it from last week, does it still make sense to do this? 18:29:52 <davideagnello> I added some, at what level do we need? 18:30:28 <sputnik13> not sure, vipul do you have thoughts on how much detail we should have in BP? 18:30:42 <davideagnello> sputnik13: I referenced the two patches that where submitted for this blueprint 18:30:58 <vipul> for things that are already done.. i don't know if it makes sense to go back and add a lot of detail 18:31:09 <sputnik13> ok, we'll call that done then? 18:31:11 <vipul> davideagnello: did you add those or did that happen via gerrit 18:31:16 <vipul> i hope it happened automatically 18:31:22 <vipul> yea i think so 18:31:26 <davideagnello> I added it 18:31:48 <davideagnello> blueprints don't seem to link automatically because gerrit looks in openstack vs. stackforge 18:31:51 <vipul> davideagnello: ok.. then something might be broken with how we refernced the bp in the commit message 18:32:01 <sputnik13> right... 18:32:03 <davideagnello> vipul: ok 18:32:10 <vipul> davideagnello: ok that might be it 18:32:13 <sputnik13> yeah blueprint links are all kinds of broke for stackforge projects 18:32:28 <sputnik13> when I click a link even in gerrit it doesn't take you to the correct bp page 18:32:50 <sputnik13> because it assumes openstack not stackforge 18:33:04 <davideagnello> I think for now we should update blueprints with patches as we commit them for now.. 18:33:27 <sputnik13> #info davideagnello added links to implementation patches to BP 18:33:55 <sputnik13> ok, let's go on we're halfway through the meeting with just AIs :( 18:34:05 <sputnik13> #info AI #7 davideagnello to add link and information to v1 API in https://blueprints.launchpad.net/cue/+spec/v1-api 18:34:33 <sputnik13> davideagnello that doesn't look done, can you add the link and any necessary information? 18:34:38 <davideagnello> sputnik13: didn't do that one.. 18:34:48 <davideagnello> yes, I will dig back and get those references in 18:34:50 <sputnik13> #action davideagnello to add link and information to v1 API in https://blueprints.launchpad.net/cue/+spec/v1-api 18:35:19 <sputnik13> #info AI #8 sputnik13 reproduce bug that fails to rollback a cluster create and file a bug with the details 18:35:54 <sputnik13> so, the cluster rollback wasn't happening because of a taskflow feature we were using improperly 18:36:28 <sputnik13> retry controllers that come with taskflow "out of the box" don't support "REVERT_ALL" on failure which is what we need in order for a complete rollback to happen 18:37:01 <sputnik13> so actually, rather than we were using it improperly, it's more accurate to say we didn't understand the ramifications fully 18:37:27 <sputnik13> a patch was submitted to taskflow to add a flag to retry controllers to choose REVERT_ALL vs REVERT on failure 18:38:00 <sputnik13> #link https://review.openstack.org/#/c/190078/ 18:38:10 <davideagnello> sputnik13: makes sense 18:38:22 <sputnik13> that has merged, so as soon as a release with that patch is made we will move the following patch in to the code base 18:38:31 <sputnik13> https://review.openstack.org/#/c/190081/ 18:38:36 <sputnik13> #link https://review.openstack.org/#/c/190081/ 18:39:01 <sputnik13> #action sputnik13 to track release of new taskflow version and ensure https://review.openstack.org/#/c/190081/ is merged 18:39:28 <sputnik13> ok last AI from last meeting 18:39:36 <sputnik13> #info AI #9 vipul davideagnello esmute abitha dkalleg to check that existing bugs have the correct classification 18:39:59 <sputnik13> not going to go over those individually, please all make sure you go through your bugs if you haven't already and make sure they're correctly classified 18:40:00 <davideagnello> sputnik13: went over my set 18:40:10 <sputnik13> cool 18:40:35 <sputnik13> I'm not going to mention that one again, we'll just let it all fall out from this point forward while reviewing bugs 18:41:05 <sputnik13> questions or anything anyone wants to raise about the Action Items? 18:41:35 <sputnik13> no? next topic 18:41:48 <vipul> i'm good.. 18:41:57 <sputnik13> #topic Tempest gate 18:42:19 <sputnik13> that's not on our agenda but I'm adding it because there was a vote on it last week to postpone a decision until today 18:42:39 <sputnik13> esmute davideagnello can you update us on the tempest gate? 18:42:43 <esmute> we have been adding more fixes to stabilize the test 18:42:51 <sputnik13> what's the failure/success rate, is it ready to mege, etc 18:42:58 <sputnik13> s/mege/merge 18:43:27 <sputnik13> esmute: when was the last fix? 18:43:29 <esmute> since last friday, it has failed around 5 times out of 18 runs 18:43:55 <sputnik13> do we know what is causing the failures? Is it anything under our control? 18:43:55 <esmute> but i feel that it is more stables than that since we have added some fixes last week 18:44:33 <sputnik13> but if it's 5/18 since friday, are you saying there were changes merged over the weekend? 18:44:46 <esmute> not really.. the test was failing becasue the cue cluster didnt come active in 30 mins... so i added a function to grab the logs from the rabbitmq as well as console-log from nova 18:44:51 <esmute> this was merged last week. 18:45:19 <esmute> there hasnt been that many patches in stackforge/cue recently to see how stable it has become 18:45:43 <davideagnello> do the logs have hints on what is wrong? 18:45:47 <esmute> 5/18 was the run done by https://review.openstack.org/#/c/187273/ 18:45:47 <sputnik13> well, I think the question is does the tempest job do what it's supposed to 18:45:48 <sputnik13> not is cue stable 18:46:01 <sputnik13> cue stability is something that the tempest job is supposed to tell us about 18:46:27 <vipul> i think we want to get the job passing consistently before i'd make it a gate to merge 18:46:44 <vipul> if it's because cue isn't stable.. then we should address those issues 18:46:50 <sputnik13> so the decision on whether to make the tempest gate voting or not should be based on our confidence in the job doing what it's supposed to 18:46:56 <vipul> if we make it voting and it's not stable.. it will be very counter productive 18:46:57 <esmute> since we havent had that many patches in, i will continue to manually do recheck 18:47:23 <sputnik13> vipul but wouldn't that make it a forcing function... and that's the point of the gate isn't it? 18:47:42 <esmute> now that we have added the logs to the tests, we should get more information about why the cluster fails to become active 18:48:03 <vipul> yes it is but we'll essentially block all non-related work as well that's teh concern 18:48:46 <esmute> what is your impressions in your patches? 18:48:47 <sputnik13> vipul I agree, but I'm also not 100% confident in the gate yet either 18:48:52 <esmute> has it been failing a lot? 18:49:01 <vipul> you think the gate itself is the issue? 18:49:02 <esmute> keep in mind that we have added some fixes recently 18:49:14 <vipul> i'd like to find out why it's failing 5/18 times 18:49:15 <sputnik13> vipul I think we don't know is the thing 18:49:34 <esmute> we have ways to get the logs now 18:49:38 <sputnik13> I'm wondering whether the default resource limits are affecting the tests 18:49:42 <esmute> and ill keep running the test manually 18:50:14 <vipul> ok as it's failing please try to dig into why.. otherwise this will lead us nowhere 18:50:19 <esmute> guys, that 5/18 was from june 1 18:50:40 <vipul> ok can you rebase to now, and let's run it 20 times and see what the current state is 18:50:41 <esmute> and i havent been manually triggering the test that much recently 18:50:47 <sputnik13> ok, you said since last friday... 18:50:56 <esmute> and we dont have enough patches. 18:51:06 <vipul> we don't need patches to exercise this 18:51:06 <sputnik13> let's rebase as vipul said and recheck 20 times 18:51:10 <esmute> sputnik13: sorry.. that was a mistype 18:51:25 <esmute> since friday i have run it twice and they both passed 18:51:30 <sputnik13> esmute we've said before that we're going to use the check job to just run recheck manually 18:51:38 <sputnik13> not relying on new patches 18:51:46 <esmute> 5/18 is from the begining until friday 18:52:10 <sputnik13> because the number of patches we have are so low that wouldn't be a good indicator of whether the tempest job runs in a reliable manner 18:52:26 <esmute> sputnik13: correct.. i've been doing that but i havent done it since recently due to vacation and other stuff 18:52:37 <vipul> esmute: i think we need new data, let's rebase and recollect data 18:52:40 <esmute> and recently, we have just added a bunch of fixes 18:53:17 <vipul> esmute: good? 18:53:28 <sputnik13> ok, just so we're all on the same page... 18:53:33 <sputnik13> we're talking about https://review.openstack.org/#/c/187273/ 18:53:35 <esmute> yes . that is what im proposing too 18:53:38 <sputnik13> let's not talk about new patches 18:53:48 <esmute> sputnik13: yes... 18:53:59 <sputnik13> the action now is to rebase https://review.openstack.org/#/c/187273/ 18:54:10 <sputnik13> then run recheck on it at least 20 times this week 18:54:33 <sputnik13> and for any failed runs assess what is causing the failure 18:54:47 <sputnik13> is this accurate? 18:55:21 <vipul> #agree 18:55:22 <esmute> yeah 18:55:25 <esmute> #agree 18:55:49 <sputnik13> #action esmute to rebase https://review.openstack.org/#/c/187273/ then run a minimum of 20 rechecks on it by 6/22 18:56:25 <sputnik13> #action esmute to present success/failure rates on tempest checks for https://review.openstack.org/#/c/187273/ and root cause analysis for failures 18:56:51 <sputnik13> we should have closure on this, it's been on the list for a while now 18:57:17 <sputnik13> we have 3 minutes left 18:57:31 <esmute> yes.. i started it in at the beginning of the month 18:57:54 <sputnik13> so we can't really talk about bugs or have open discussion today :( 18:58:10 <sputnik13> starting next meeting we need to try and blast through AIs more quickly 18:58:11 <esmute> ill try to be on top of this but if you see that a run finished and there is no 'recheck no bug', feel free to add it to https://review.openstack.org/#/c/187273/ 18:58:39 <sputnik13> esmute: ok 18:59:18 <sputnik13> abitha dkalleg you're both too quiet 18:59:23 <sputnik13> :P 18:59:29 <dkalleg> Just reading along :) 18:59:35 <abitha> me too 18:59:46 <dkalleg> Havn't been part of any AIs 18:59:47 <sputnik13> you can at least agree or disagree to things :P 19:00:10 <vipul> time's up 19:00:18 <sputnik13> I don't want this to be meetings about AIs, so starting next meeting I will try and just push through them as quickly as possible 19:00:28 <vipul> +1 19:00:34 <dkalleg> #agree 19:00:46 <esmute> lunch time!! 19:00:47 <sputnik13> anyone who has AIs should come having reviewed their list beforehand 19:00:48 <sputnik13> so we can blast through 19:01:02 <sputnik13> good? 19:01:10 <sputnik13> yeah #lunchtime 19:01:11 <sputnik13> :) 19:01:17 <sputnik13> thanks everyone 19:01:19 <sputnik13> #endmeeting